Hi Andrus, yeah, I'm going to try out the OC subclass thing, hook into it in some places and see what explodes.
As for the use case, I've been changing an older app from using a session-scoped ObjectContext (that was used basically everywhere) and some other bad OC hygiene, to use more local scoped/short lived ones. Due to the nature of the previous design I've encountered a class of errors where work was being done in the wrong context and (a) getting lost—or (b) modifications getting saved when they shouldn't. So I see this as a way for me to catch these types of errors earlier in the process. I see myself using this generally as well, to protect me from my own inadvertent bad coding :). Cheers, - hugi > On 15 Oct 2019, at 13:00, Andrus Adamchik <[email protected]> wrote: > > Hi Hugi, > > There's only so many options considering that the framework does not provide > any explicit API for this. Yours is as good as any. > > Curios about a specific scenario why you need it. > > Andrus > >> On Oct 15, 2019, at 6:26 AM, Hugi Thordarson <[email protected]> wrote: >> >> Hi all, >> i'm looking for suggestions on an approach to mark an ObjectContext as >> "obsolete", i.e. to explicitly state that I'm now done with it and any >> further operations on it (preferably even any objects in it) signify a >> logical error/bad state. >> >> First thought is to create my own DataContext subclass with a simple boolean >> marker, and override methods like commitChanges() and onQuery() to throw an >> exception if the marker is set. At least that provides partial safety. But >> I'm wondering if anyone has suggestions for a better approach? >> >> Cheers, >> - hugi >
