Definitely test your delete rules. Sounds like you just forgot to properly set delete rules on the relationship
> On Feb 25, 2022, at 2:50 PM, ocs--- via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > Hi there, > > lately, I was for the first time in a quarter of century of working with > WO/EOF bitten in my tender parts by the following scenario: > > - there's a 1:N relationship > - one of its objects is deleted using the plainest > “eo.editingContext().deleteObject(eo)” approach > - which deletes the object all right, but _keeps the relationship snapshot > EODatabase-level unchanged_ > - thus, if now e.g., another user logs in and uses the relationship, he gets > (from the snapshot, presumed his EC has old enough fetch timestamp) a list of > gids containing one for the non-existing object, leading to > “ObjectNotAvailableException: No <class> found with globalID <the one lately > deleted>” > > Until now, I've naïvely thought EOF would solve all such problems > automagically inside of the saveChanges code (i.e., that among many other > things, if a deleted object is part of a relationship, it gets automatically > and properly removed; snapshot-level immediately upon save, in all the ECs > later when they process the appropriate notification). So far it seemed to > actually happen, always and reliably. Weird. > > Looks like in fact this does _not_ happen, but I _do_ wonder. While the > natural fix of course is to remove the object from the relationship(s) first > (e.g., through removeObjectFromBothSidesOfRelationshipWithKey), and only then > delete it (unless the relationship happens to be owning, in which case the > deletion is not needed and happens automatically), there are _many_ cases > where this approach could lead to problems, e.g., > > (i) objects which could be part of _many_ different relationships. Should we > really manually remove the object from _all of them_ before we delete it? > > (ii) what about relationships without an inverse? While EOF might be able to > track internally those which (a) contain a given object, (b) and are in > snapshots, and clean them up upon object deletion, I can't see any reasonable > way to do that from the application-level code; > > (iii) what if the app is being improved, and an already existing object is > added into a new relationship? That object might be deleted for years through > ec.deleteObject (or a plethora of other means, like WODisplayGroup, > you-name-it). With a big legacy project it well might get next-to-impossible > to find all such places. How do we ensure all the relationship snapshots > which might contain the deleted object are properly cleaned up? > > How do you solve this kind of problems? > > And one bonus question: how comes the problem is rare enough that I've never > bumped to it until now? Far as I understand, when one deletes objects using > ec.deleteObject (I do most times), and when those objects are part of > relationships (many of them are), it should be pretty common. It is not, for > whatever reason. > > Thanks for any insight, > 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
