Re: Baffling problem with foreign key
Re: Baffling problem with foreign key
- Subject: Re: Baffling problem with foreign key
- From: Chuck Hill <email@hidden>
- Date: Wed, 3 Dec 2008 12:08:39 -0800
Hi Gary,
Nice to see you around!
On Dec 3, 2008, at 10:11 AM, Gary Teter wrote:
This one has had me scratching my head for two days. I have a
situation where I can set a to-one relationship on an eo but the
change to the foreign key is not reflected in the SQL emitted during
saveChanges.
This code works properly in most circumstances, but a customer found
that if you follow a very specific series of otherwise completely
ordinary actions that work perfectly well in any other context, then
at some point EOF gets confused. The object graph no longer matches
what's in the database.
I think the particular sequence of user actions is a red herring,
but they're along the lines of, "Add two products to your cart.
Proceed to checkout. Change shipping address. Remove item from cart.
Proceed to checkout. Change shipping method." (This is the
relationship that becomes borked.) We process tons of orders every
week with this code, so it's not like the shipping method
relationship is simply broken.
It is possible that an EO is getting removed from an EC and then
altered? This may produce the same bugs that modifying an EO before
it has been inserted cause. I take it you can reproduce this yourself
and that no back tracking or multiple browser windows are involved?
It is possible that an EO is getting removed from an EC and re-inserted?
It is possible that these steps are resulting in an EO in an unlocked
EC getting altered?
I'm pretty sure I've eliminated threading and remote synchronization
as possible culprits (can still duplicate with those turned off).
This is WebObjects 5.3.3.
The following are true when it's failing:
I can repeatedly change the destination object, save changes, and
not see the proper update statement.
If the object has other changes that need saving, an update
statement gets properly generated for those attributes, but not the
changed foreign key.
Logging statements in the setBorkedRelationship(OtherObject value)
method show that the relationship is being set properly.
Overriding snapshot() and changesFromSnapshot() show that during
saveChanges the current snapshot includes the new value, and so does
the snapshot being compared. This is definitely not normal, usually
the snapshot being compared will include the old value, so that
changesFromSnapshot() will indicate the foreign key needs to be
updated.
That really does sound like what I was seeing when modifying an EO
that was not yet in an EC. Is the only updated data in the snapshot
being compared the FK? The other updated values only appear in
snapshot()? Is this key getting propagated from some other object? A
mutable value can also do this, but I can't see you using an mutable FK.
If the foreign key is marked as "use for locking", the update SQL
will properly include the >old< foreign key in the where clause, but
the foreign key column is not in the list of columns being updated.
This is interesting to me because one of my theories was that
somehow the EODatabase's snapshot was getting updated behind my back
somehow to reflect the new value. But this indicates to me that the
committed snapshot does in fact have the correct (old) value.
Wow. That is odd. That makes it seem as if the problem is local to
that EC.
If I modify a different to-one relationship and save changes, that
change gets reflected properly, and I can then successfully change
the previously borked relationship.
Maybe saving that change resets the internal EC state?
I must be breaking some EOF commandment but damned if I can figure
out which one.... Suggestions, hints, theories greatly appreciated.
That is the best I can do at this point.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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