Re: Marking an ObjectContext as "done, don't use"

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 <[email protected]> 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 <[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
> >
>
>