IIRC, the issue is:
EOEditingContext ec1 = ERXEC.newEditingContext();
ec1.lock();
Car c1 = Car.fetchAllCars(ec1).objectAtIndex(0);
EOEditingContext ec2 = ERXEC.newEditingContext();
ec2.lock();
Car c2 = c1.localInstanceIn(ec2);
c1.setName("New Car Name 1");
c2.setName("New Car Name 2");
ec1.saveChanges();
ec1.unlock();
ec2.saveChanges();
ec2.unlock();
you don't get an optimistic locking failure in step #6, because the
editingcontext automatically merges changes, and the backing snapshot is
updated.
Mark would say that you address this by implementing the
editingContextShouldMergeChangesForObject method on EC.Delegate, but IMO, that
really makes your work for it. There is some truth to what Miguel says ... It
does seem odd that within a single instance, you simply don't get OL failures.
You only get them from multiple instances or outside data editors. To make that
delegate behave in the same way, you have to keep your own snapshot changes in
your delegate and check them prior to the EC committing, essentially
implementing OL yourself.
The proper fix for this is to have the EO keep its original snapshot from the
point when it was brought into the EC, and use THAT for the OL update clause
rather than the shared snapshot cache. The problem with this is that I think
people will constantly get OL failures a LOT more than before for relatively
normal cases. You could probably tweak this behavior to automerge any object as
long as it hasn't been touched in your EC.
Regardless, Miguel's not totally crazy :)
ms
On Sep 24, 2010, at 1:33 PM, Alan Ward wrote:
>
> Maybe I shouldn't ask.... but it's killing me not to. What exactly doesn't
> work about it?
>
> Alan
>
> On Sep 24, 2010, at 10:45 AM, Mike Schrag wrote:
>
>>> because OL doesn't work anyway ;)
>> uh oh .. here he goes again :)
>>
>> ms
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/award%40apple.com
>>
>> This email sent to [email protected]
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
