Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <509A2A69.1090105@gdcjk.com>
Date: Wed, 07 Nov 2012 03:31:21 -0600
From: Garth Keesler <garthk@gdcjk.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: user@cayenne.apache.org
Subject: Re: setToOneTarget not works for two transient objects (3.1B1)
References: 
 <CAEXeD-0rd40nCSQCGfB1wigy01v0est4BtNtJTtvNPiM87YAtg@mail.gmail.com>
 <5099F2BB.30606@maniatis.org> <loom.20121107T063834-43@post.gmane.org>
 <509A0509.2090707@maniatis.org>
In-Reply-To: <509A0509.2090707@maniatis.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>
>