RE: Ordering of operations in editingContext
RE: Ordering of operations in editingContext
- Subject: RE: Ordering of operations in editingContext
- From: "dov rosenberg" <email@hidden>
- Date: Thu, 28 Aug 2003 17:53:20 -0400
The deferrable option on a constrainst is designed to solve the problem with
circular types of relationships. i.e. Person might have relationships to
another table and vica versa. It is also helpful when a single entity has a
lot of other relationships to other Entities. If you try to delete an entity
that has lots of relations, you might find your self screwed over when EOF
decides how to order the transactions.
We had a situation where a single entity was related either directly or
indirectly to a lot of other things. If we tried to delete the entity, we
would run into a "Can't insert null for primary key" error or something
similar when EOF tried to nullify the other side of a relationship. By
deferring the constraint until after everything was completed, the problem
goes away.
We haven't come across the situation you described in your sample. It seems
though that it might be a bad design to capture that type of transaction in
one place (not sure how or why that would occur). If someone changes their
mind on a form, wouldn't a RESET of the form prevent that scenario from
occuring? Capturing and processing multiple changes to the same record in a
sequential manner seems kind of dangerous to me. I suspect that your sample
was a theoretical one - not sure how that would be handled with a deferrable
constraint. Probably as you describe. Just don't think it would present
itself in the real world.
Dov Rosenberg
-----Original Message-----
From: Kaj Hejer [mailto:email@hidden]
Sent: Thursday, August 28, 2003 5:10 PM
To: dov rosenberg; email@hidden
Subject: RE: Ordering of operations in editingContext
At 09:30 -0400 28-08-2003, dov rosenberg wrote:
>we tried ordering the operations manually but it was too unreliable. On
>oracle and postgresql there are options to make the costraints deferrable
>until after the transaction has completed before applying the constraints.
>Things will still rollback if there is a problem, it just allows all of the
>operations to go thru first without having to muck around in the bowels of
>EOF. Seems to work pretty well.
Hi!
Thank you for answering!
If we have a table like
PERSON (username [pk], full_name); // empty table
and perform the following in our application (with ec.insertObject
and ec.deleteObject):
insert ('endremr', 'Endre Rognerud');
delete ('endremr', 'Endre Rognerud');
insert ('endremr', 'Endre Rognerud');
saveChanges();
When the sql is gererated by EOF this might turn into
delete ('endremr', 'Endre Rognerud'); // nothing to delete (error)
insert ('endremr', 'Endre Rognerud'); // maybe ok
insert ('endremr', 'Endre Rognerud'); // duplicate (error)
For this example we can't see how making the contraint deferrable will help
us.
-Kaj :)
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.