Re: multi-instance sync woes
Re: multi-instance sync woes
- Subject: Re: multi-instance sync woes
- From: OC <email@hidden>
- Date: Wed, 26 Nov 2014 00:03:10 +0100
Chuck,
On 25. 11. 2014, at 23:32, Chuck Hill <email@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden