Ha! Indeed, thanks a lot: having added extra logs I've found what I stupidly overlooked for a long long time, i.e., that I've switched relationships and have set Nullify for the one which does not have an iverse, and NoAction to the one which does. That explain essentially all the problems.
(Hm, I guess I should learn to set Nullify for no-inverse ones as well, to keep at the safe side. Far as I can say it is completely harmless, it just feel... improper, sorta :)) Thanks a lot! OC > On 25. 2. 2022, at 23:15, Jesse Tayler <jtay...@oeinc.com> wrote: > > 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
