|
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.
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.
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.
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.
I must be breaking some EOF commandment but damned if I can figure out which one.... Suggestions, hints, theories greatly appreciated.
-- The Ent visualization project:
|