• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: Ordering of operations in editingContext
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

References: 
 >RE: Ordering of operations in editingContext (From: "dov rosenberg" <email@hidden>)
 >RE: Ordering of operations in editingContext (From: Kaj Hejer <email@hidden>)

  • Prev by Date: RE: Ordering of operations in editingContext
  • Next by Date: RE: Ordering of operations in editingContext
  • Previous by thread: RE: Ordering of operations in editingContext
  • Next by thread: RE: Ordering of operations in editingContext
  • Index(es):
    • Date
    • Thread