Fredrik Liden <flide..ranslate.com> wrote:
> So would it be possible to create a object graph in a non-shared
> DataContext. And then somehow transfer that whole graph over to the
> shared context assuming there are no errors?
You're asking for a nested DataContext. It's not available in Cayenne yet,
but it probably will be in the next few months as a lot of people (including
my own programming group) have expressed a need for it.
For now, you'd have to manually do this with
sharedDataContext.localObjects().
> Also, how is the temporaryDataContext different from a non-shared
> DataContext?
I can't remember the context I used temporaryDataContext in, but I think
temporaryDataContext was an instance of a non-shared DataContext.
-Mike
> > -----Original Message-----
> > From: Mike Kienenberger [mailto:mkienen..laska.net]
> > Sent: Wednesday, February 16, 2005 7:06 AM
> > To: cayenne-use..bjectstyle.org
> > Cc: cayenne-use..bjectstyle.org
> > Subject: Re: The life of a DataObject
> >
> >
> > Fredrik Liden <flide..ranslate.com> wrote:
> > > When creating a Web application.
> > >
> > > Can I fetch a dataObject to view it on a view page.
> > > Then modify the contents of this dataObject (without comminging)
> > > over
> > > serveral requests cycles and then finally commit the changes.
> > >
> > > In other words, can I store the dataObject in the session so I don't
> > > have to fetch again for every trip to the server during some
> updates,
> > > or do I have to fetch it every time a request is processed? How long
>
> > > can a dataObject stay active before I can no longer commit it? Do I
> > > need some buffer object like a VO object or JavaBean?
> > >
> > > Are there any guidelines for a good design?
> >
> > I don't think there's any technical reasons why you couldn't do this.
> >
> > However, I consider it a bad design to leave DataObjects in a
> > modified, new, or deleted state between requests.
> > There's never a guarantee that the user will submit the next page, nor
> > is
> > there any guarantee that the user won't hit the back button a couple
> of
> > times and start working from that point, leaving your DataContext
> > objects in
> > a strange state.
> >
> > Let's assume you're using one DataContext per session. You start
> > creating
> > a new Artist object due to a user request, but don't finish collecting
> > all
> > of the information and thus don't save it. The user suddenly
> > back-navigates (or side-navigates) away from your Create Artist page
> to
> > a
> > Delete Painting page. He deletes a painting and triggers commit.
> At
> >
> > this point, the incomplete Artist object is still in your context and
> > gets committed as-is (or it causes a validation error and makes the
> > deletion fail).
> >
> > I generally collect information required to make a change separately,
> > then move it all into the DataObject and commit it in one
> > request/response cycle.
> >
> > On the other hand, I have very few instances where data is collected
> > in a multistep process.
> >
> >
This archive was generated by hypermail 2.0.0 : Wed Feb 16 2005 - 17:15:48 EST