Re: EOF Stumper (for me at least)
Re: EOF Stumper (for me at least)
- Subject: Re: EOF Stumper (for me at least)
- From: Chuck Hill <email@hidden>
- Date: Mon, 18 May 2009 19:05:13 -0700
On May 18, 2009, at 6:15 PM, Lon Varscsak wrote:
I'm not sure. When I fix the null primary key thing (by not using
propagate primary keys) then the constraint violation happens.
Is this a join table where EOF might be deleting and then inserting
the "same" row (related object removed then replaced with same
object)? The constraint violation problem seems particularly insane.
Have you considered that the database indexes might be corrupt? Does
this problem exhibit on more than one database?
Again, it only happens about 10% of the time....for the life of me
I have no idea. I've been using EOF since WO was in pre-release and
I am absolutely stumped.
That sure sounds like concurrency and notifications and something not
locked somewhere. You could try logging out ALL of the notifications
flying around and see if there is any difference when it fails. That
might lead you somewhere. Or not.
I'm close to being willing to bribe someone to fix this for me,
because my project has come to a grinding halt.
I've been driven close to much worse things. ;-)
Chuck
-Lon
On Mon, May 18, 2009 at 5:58 PM, Chuck Hill <chill@global-
village.net> wrote:
Hi Lon,
This and your other problem cause me to suspect that you are
violating an EOF commandment somewhere. The "it works sometimes and
not others" is often indicative of a violation somewhere. Perhaps
in this process? I am also unsure that Propagate Primary Key is
intended to be used with a partially user controlled PK. I don't
know that is not, but it sounds suspicious.
On May 18, 2009, at 2:27 PM, Lon Varscsak wrote:
I'm having a problem where sometimes a compound primary key value
that I assign myself, get's overwritten to null somewhere and the
insert statement fails.
OrderHeader (primary key orderNumber)
->> OrderDetailSale (to many relationship, primary key orderNumber
& orderLineNumber; both owns destination and propagates primary keys
checked)
1. create an OrderHeader object
2. create (and assign to the OrderHeaderObject) an OrderDetailSales
object
3. assign regular property values
4. set orderNumber on the orderHeader object (only this object,
because I want EOF to assign it to the detail relationship; which it
does)
5. set orderLineNumber on OrderDetailSales object
6. save.
When I save Sybase complains that the order_line_number column
cannot be NULL. However, the object DOES have orderLineNumber
assigned (and so does it's snapshot). When I log out the
EOAdaptorOperation's changedValues it has orderLineNumber as null
(which is wrong and bad).
The worst part of this is that without any code changes sometimes it
works and sometimes it fails (meaning sometimes orderLineNumber is
written to the adaptor op properly and therefore the database...but
not always).
I have changed "propagates primary keys" and propagated it myself by
overriding the setOrderNumber method on OrderHeader (and then
passing it down to OrderDetailSale) and the error goes away
completely. I'd prefer not to do this as it really does propagate
orderNumber which I want, it just seems to be occasionally trampling
orderLineNumber.
Any ideas?
Thanks,
Lon
P.S. -- Using WO 5.4.3 & Project Wonder from about a month ago.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden