Chuck,

On 25. 11. 2014, at 23:32, Chuck Hill <[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.

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!!!

> 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

Thanks again,
OC


 _______________________________________________
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]

Reply via email to