cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garth Keesler <>
Subject Re: setToOneTarget not works for two transient objects (3.1B1)
Date Wed, 07 Nov 2012 10:42:05 GMT
Interesting. So your ROP App is shared read, per user write. Right? In 
that case, can multiple users be changing the same object from the 
read-only context or do you move the object to the dedicated writable 
context? This would seem to place the work of concurrency back on the 
database, correct? Is this a requirement with Cayenne, much as it was 
with Ibatis (now Mybatis)? I guess my REAL question is this: Is Cayenne 
designed to be an Object Manager or an Object Relational Mapper, 
particularly in the ROP environment where multiple users interact with 
the same server app simultaneously?

I've done a lot of reading about Cayenne but this remains unclear to me.


On 11/07/2012 04:22 AM, Aristedes Maniatis wrote:
> It all depends. One usage pattern is to create a long lived 
> "read-only" context which handles the bulk of data in the application 
> which is not editable by users. Then you'll use localObject to copy 
> objects into a new context as needed (perhaps a shopping basket in a 
> web application).
> In my thick client ROP application, we have one shared context used 
> for all the list views (not editable). But when a user double clicks 
> on a row, we create a new editing context into which they will save 
> any changes. They might have 10 windows open at once, so we we have 10 
> contexts. When they save a window, we save the context and throw the 
> whole thing away.
> We also create child contexts for 'sheets'. (Think OSX style dialogs 
> which are modal within a window).
> For web applications, having a single context which lasts as long as 
> the session is probably quite a common pattern.
> Ari
> On 7/11/12 8:31pm, Garth Keesler 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

View raw message