Hey Mike,
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?
Also, how is the temporaryDataContext different from a non-shared
DataContext?
Fredrik
> -----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:07:56 EST