Re: EOF Stumper (for me at least)
Re: EOF Stumper (for me at least)
- Subject: Re: EOF Stumper (for me at least)
- From: "Robert B. Hanviriyapunt" <email@hidden>
- Date: Mon, 18 May 2009 23:49:22 -0500
Just wanted to say that it sounds to me that you manually assign your
primary key attribute (as opposed to primary key generation [EO_PK or
whatnot])
- I personally don't let my app set primary key attributes outside of
a custom primary key generator EOF delegate
Your problem IS puzzling and makes me even more curious about (not
that I really know anything even cursory to) EOF internals for timing
of (possible random order for both) primary key assigning and
propagation, especially in light of manual key attribute assignments
like yours.
I wonder if EOF looks somewhere else to see if an EO has the primary
key for propagation and then gets the value from somewhere else.
My thoughts are to make the following call somewhere in a dummy EOF
delegate (not that I know where, as I am not really experienced in
that area at all) that assigns primary key (returning the one the EO
has or whatnot) and then call something else in the EOF toolbox like:
EOUtilities.primaryKeyForObject( orderHeader.editingContext(),
orderHeader );
EOUtilities.primaryKeyForObject( orderDetailSales.editingContext(),
orderDetailSales );
Where it could internally be looking as an alternate source for the
value for the EO's primary key (which by timing could have it NULL at
the time).
I wonder also then when in this whole time this is true or not, and
if it affects getting the pk attr value or where to get the pk attr
value for propagation:
editingContext().globalIDForObject( orderHeader ).isTemporary()
editingContext().globalIDForObject( orderDetailSales ).isTemporary()
I have no real background to say I really know anything about this
stuff. I'm just seeing if I can help in any way.
= Robert =
ps. I wish I could do more WO/EOF/Java and go to WOWODC and meet
y'all WO-heads! I've been doing WO for a pretty long time myself
(but I'm not great or anything).
On May 18, 2009, at 9:05 PM, Chuck Hill wrote:
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:
40global-village.net
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:
40scologistics.com
This email sent to email@hidden
_______________________________________________
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