In memory you will have a temporary ID and it doesn’t seem possible to interfere or duplicate in any practical sense, it’s local.
Once stored in the DB it will have a key, which is generally tied to a “by-hand” method of generation, but I think everyone accepts that who uses EOF and I don’t seem to mind. Keys have locking and can come into memory in a batch to better ensure a save without repeating, but even then I’m pretty sure a DB unique failure will only result in fetch/save of a new key (integer) that is controlled by the DB. In short, no, you should not have to worry about that. > On Sep 15, 2025, at 11:09 AM, OCsite via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > Hi there, > > presumed I use integer PKs and don't ever assign them myself, leaving it on > EOF, can I rely on that never a newly created EO would get same PK as used to > have one deleted previously? Or is there some rare scenario when this may > happen? > > I need to store some information for EOs (which would be very rarely deleted, > but occasionally it might happen) in a map whose keys would be the PKs (the > map itself persists archived in a BLOB of another EO). I wonder whether I > have to observe deletions and update these maps accordingly, or whether I can > afford to simply keep PKs and information for deleted EOs in there without > any real harm. > > Thanks! > OC > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com > > This email sent to jtay...@oeinc.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com