Chuck, thanks!
It looks like the cleanest possible solution indeed. Alas the drawback is that the change won't be located nicely to one place -- I would have to find all the places in code anyone makes an EC, and change its class. To be frank, I am not even sure which WebObjects/WOnder services might create an EC... (a) session creates defaultEC, that will have to be fixed somehow, (b) my own (ERXEC|EOEditingContext).newEditingContext calls throughout the whole project, (c) anything else to be wary of? Or is there perhaps a Java/WOnder trick I am not aware of, which would allow me to create an ERXEC subclass, and globally set it up so that “wherever and how-ever an EC gets created, it will always be my class”? Thanks a lot, OC On 21. 3. 2016, at 21:23, Chuck Hill <[email protected]> wrote: > As a first idea, you could make an EC subclass that was able to identify > these ready only instances and not call super in deleteObject(). > > Chuck > > > > > > On 2016-03-21, 1:17 PM, > "[email protected] on behalf of OC" > <[email protected] on behalf of > [email protected]> wrote: > >> Hello there, >> >> is there a trick to “undelete” an object in editing context? >> >> Before saveChanges, I go through ec.deletedObjects(), and in some very >> special cases, I might find that an object should NOT be deleted. Just like >> it has never been added to deletedObjects at all. >> >> I've tried to insertObject it immediately; that works all right for the >> object itself, but still removes its owned :1 relationships, which is also >> quite wrong. >> >> Is there a way to do it right? >> >> Note: if there was a way to mark specific objects as read-only (never to be >> deleted, never to be updated), it would be even better; but I've tried to >> override isReadOnly, and it does not seem to be even called from >> saveChanges. I can't make R/O the whole entity: it applies to only some of >> its objects. I can't throw from validateForDelete either: I don't want >> saveChanges to fail. I need it to work all right with all the other objects, >> just not deleting a couple of special ones (nor their owning relationships). >> >> Thanks, >> OC >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com >> >> This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
