On 2014-11-25, 3:02 PM, "OC" wrote:
Chuck, On 25. 11. 2014, at 23:32, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: 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. Chuck
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
