Session-scoped isn't always bad, but it really depends on the nature of the application. Worked on one where the user would select a line item to edit and that could fetch in hundreds or even thousands of associated records (which could take a while to load). We'd keep them in a session-scoped OC to use while they were editing. But if they later went and selected a new line item to edit, we'd replace the session-scoped OC with a new one (and allow the old one to GC) and use the new one for future edits. No chance of bleeding that way, but, if the OC had a way to mark it as dead, I'd have probably marked the old one dead just to satisfy my general paranoia.
On Wed, Oct 16, 2019 at 9:39 AM Hugi Thordarson <h...@karlmenn.is> wrote: > 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 <and...@objectstyle.org> > 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 <h...@karlmenn.is> 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 > > > >
