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
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
