cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: setToOneTarget not works for two transient objects (3.1B1)
Date Wed, 07 Nov 2012 14:00:10 GMT
A data context is a unit of work.  What that means is that for a
particular task, all transaction changes are collected and then
committed at the same time, or thrown away at the same time leaving
you back at the initial state.

I think of a data context as a piece of paper where I'm going to plan
a change to the database.   Sort of a "what if we do this" kind of
concept.  In the case of a web page this might happen on one request
or it might happen across several requests.    But at some point, I
either get to a places where I commit all these related operations, or
the plan is abandoned.

On Wed, Nov 7, 2012 at 4:31 AM, Garth Keesler <garthk@gdcjk.com> wrote:
> Is the general case that a context typically lasts as long as the
> transaction, gets discarded, and a new one is created for the next
> transaction or is it dependent on usage in the program? For example, a web
> app as discussed here discards contexts based on user interactions while a
> thick client app would tend to reuse the same context.
>
> Just curious...
> Garth
>
>
> On 11/07/2012 12:51 AM, Aristedes Maniatis wrote:
>>
>> On 7/11/12 4:57pm, Alexey Katorgin wrote:
>>>>
>>>>
>>>> You should always create a context and then create objects within that
>>>> context
>>>
>>> using the methods Cayenne
>>>>
>>>> gives you. This is different to the undecorated POJO that Hibernate
>>>> allows you
>>>
>>> to create.
>>>>
>>>>
>>>> Ari
>>>>
>>>
>>>
>>> I develop a web-app and if I will create entities bounded to a
>>> dataContext, and
>>> after user has leaved the page (by browser navigation buttons, closing
>>> the tab,
>>> etc.) such entities will stay uncommitted and may be in inconsistency
>>> state
>>> (user has not filled all required fields). And on the next commit this
>>> objects
>>> will be committed and raise validation exception.
>>>
>>> It is the reason why I want to use unbounded dataObjects.
>>>
>>> So I've decide to use transient objects not bounded to any dataContext.
>>> In this
>>> case such object just be removed by garbage collector after user leaved
>>> page
>>> unexpectedly. And where user will click OK, such objects will be manually
>>> attached to a dataContext and committed.
>>>
>>> It makes my code less clearly if can't set relationships between
>>> transient
>>> objects. Because I need to create additional temporary lists to store all
>>> transient entities and iterate its to register to a dataContext before
>>> committing.
>>>
>>>
>>> What is the best practice for this use case?
>>
>>
>>
>> Typically you bind a context to the user session so that the user can
>> continue to navigate through the site and not lose the work they have done
>> but not yet saved. For example, they may assemble a shopping basket, contact
>> details and payment information. Then you commit the whole thing atomically
>> at the end.
>>
>> Don't think of a data context as something you create when you are ready
>> to save. Think of it as a big bucket into which you put all the objects you
>> are working with. At the end, throw it away and make a new one, or commit it
>> to the database. For more complex arrangements read up on how to create
>> parent/child contexts, but you don't need to do that here. Start simple.
>>
>> Make as many contexts as you need to have buckets of different
>> information.
>>
>>
>> Ari
>>
>>
>

Mime
View raw message