How about EOF doing things out-of-(expected)-order?
ec.saveChanges() creates 1 transaction.
Let’s say you’ve made a bunch of changes, one of which results in an EO being deleted (cascade-delete, owned objects, etc), but because other EOs that would have been related to it were added before it was deleted from the ec.
I’ve run into situations where an EO is inserted and then deleted by one saveChanges call, only EOF tried to do the delete first which, obviously, failed. I know EOF does not deal with this on it’s own. I found some code in wonder a while ago
that deals, I believe, with the situation of inserting and deleting EOs with flattened join tables (consisting of only a compound PK) in one transaction where it simply removes the insert and delete SQL statements from the query. I can’t remember where I saw
it and can’t find it now.
Dave
On Feb 5, 2015, at 1:26 PM, Chuck Hill <
email@hidden> wrote:
I can think of a few off-the-wall reasons.
- The EOF internal state somehow got scrambled. Good luck with that one!
- Some other process (non-EOF) is connected to the database and had that row locked in a way that prevented it from being read
- Some code changed the EODatabase snapshot which resulted in the WHERE clause being wrong and then the code changed it back
- Ghosts in the machine
—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™
—————————————————————————————
David Avendasora
Senior Software Abuser
Nekesto, Inc.