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 <[email protected]> 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 >> >> >
