RE: Ordering of operations in editingContext
RE: Ordering of operations in editingContext
- Subject: RE: Ordering of operations in editingContext
- From: Jonathan Rochkind <email@hidden>
- Date: Thu, 28 Aug 2003 16:38:31 -0500
At 11:09 PM 8/28/2003 +0200, Kaj Hejer wrote:
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)
I can't figure out what those methods insert and delete do that will cause
that SQL. I don't think the EOEditingContext works like you think it does.
In order to delete an EO, you've got to HAVE an EO to delete, and in order
to have an EO to delete, you've got to either insert it, or fetch it. If
you insert an EO and then delete it, and then call saveChanges----no SQL
will be generated. If you insert, delete, and then insert the SAME EO
again, it will simply be inserted, all is well. If you insert an EO,
delete that same EO, and then insert a new EO with the same pk----then you
could very well encounter an exception, but I'm not sure if you'd get it on
insert, even before you call saveChanges, or if you'd get it on
saveChanges. And depending on exactly what's going on, deferred
constraints _might_ help.
If you insert an EO, delete it, then fetch an EO with that same pk value,
and delete it---again, it's possible that you'll get an exception even
before saveChanges, but if you don't, you're not going to get one at
saveChanges.
So, whether or not you will have problems, and the nature of the problems,
depends on exactly what you are doing. It's possible the code could be
rewritten to not cause any "side effect" problems, to not cause any
problems unless you are actually trying to insert an EO that already
existed from some other process or EC, or delete one that's already been
deleted by an entirely different process or EC. This may not be an issue
of ordering operations.
I would agree with Chuck that the username ought not be a pk, the pk ought
to be a meaningless value. But then, you would want to put a unique
constraint on the username column anyway, and you'll have somewhat similar
issues, although actually probably fewer.
--Jonathan
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.
_______________________________________________
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.