On 2014-11-25, 3:02 PM, "OC" wrote:
Chuck,
Interesting. I think your setting of the PK is confusing EOF as it identifies objects with a combination of Entity and PK. So you have one EO in memory marked as “new, to be saved” and another one that has been fetched and is obviously not new. I will
assume that changing to not use a PK that you define is not an option at this point in time.
Alas nope, though it's one of things I am looking forward to trash at the very first possible occassion.
It is an ancient and rather convoluted code whose purpose was more-or-less to simulate a shared editing context, which -- can't recall clearly now -- either was buggy then, or there was some other problem with the thing.
It might still be buggy.
The result is a proper mess which I have to live with -- hopefully, not for long.
What if you do this when the exception arises:
• Set relationships to this EO to null
• Delete the object to get it out of inserted objects
• Fetch the object
• Set the relationships to the fetched object
• Save again
At the first look this seems it did help indeed!
Now I'll implement the save/restore relationship stuff (to test I went without, for it so happens the offending object does not have any non-null relationship), and put it to more thorough testing.
Thanks a very big lot again!!!
You are very welcome.
The EOGlobalID is the same but the inserted state is captured in the EC. How hard would it be to re-create the whole set of objects to be saved in a different EC?
Hmmm.... another option, if this one fails. Thanks!
By the way, the multi-instanceness brought consequences I did not quite foresee. E.g., the application sometimes imports CSV, doing these steps:
1. keep-track-of-old-records
2. read-in-CSV-and-create-new-records
3. delete-old-records
4. save
If two instances do this at once, hilarity ensues: all the old records of the slower instance are deleted by the quicker one before the slower one gets to save -- but after it started, so it tries to delete them itself, too; thus _all_ the deletion operations
of the slower instance one-by-one fail, throw an exception, make me to 'forgetObject' and try again. Great.
I must be missing something pretty obvious -- there must be a considerably better approach to this :-O
In cases like this, I have created a second application that does this sort of processing and only allow a single instance of that to run. Otherwise, you can create a locking table in the database and get the lock before importing and release it when
done. I use a separate application if there is a lot of background daemon type processing to do.