> But I mention the pattern because one thing I've been considering
> doing in one particularly complicated workflow is to have an
> accumulator object graph that never actually gets committed, but
> when the user saves or changes something a new datacontext is
> derived from it. A bit expensive on memory and processing, but
> probably an easy way to achieve what would otherwise be quite a
> complicated algorithm. Maybe this is something you could consider.
I am eager to explore nested contexts for complex workflows with the
ability to roll back sub-flows in memory without rolling back the
entire thing. In fact nested contexts were designed with such
scenario in mind.
Andrus
On Mar 27, 2006, at 8:08 AM, Craig Turner wrote:
> Malcolm Edgar wrote:
>> I am finding that with the Cayenne web app design pattern where
>> the DataContext has session scope, it is easy to add objects to
>> the DataContext when building up an object graph for display. If
>> these objects aren't explicity committed by request it is easy to
>> have them carried forward in the session DataContext, and have
>> them committed in a subsequent but unrelated request.
>
> In the past I have had problems where the user will fail validation
> on one screen, move to another, attempt a save, and then run into
> problems because objects from the old screen are still sitting in
> the datacontext.
>
> I get around this these days by using different DataContexts for
> different flows. Each subsystem in my app is associated with a
> different 'workflow' in the engine, and each workflow has its own
> DataContext. I've been very happy with this pattern. And if there
> are situations where one updating can have flow-on-effects to
> another, then I get that workflow to reset the affected workflows
> so that they'll be built up from scratch again if the user returns
> to those screens. As my app is a webapp this is acceptable usage -
> in fact I've been very happy with this pattern.
>
> One of the advantages of cayenne over EOF (at least in my
> experience) is that you can remove things from the graph after
> adding them, which makes it nice as a hacky object-graph-on-demand
> even for things that you'll never persist to the database. But I
> find that using multiple datacontexts I rarely need to remove
> things from the graph.
>
> But I mention the pattern because one thing I've been considering
> doing in one particularly complicated workflow is to have an
> accumulator object graph that never actually gets committed, but
> when the user saves or changes something a new datacontext is
> derived from it. A bit expensive on memory and processing, but
> probably an easy way to achieve what would otherwise be quite a
> complicated algorithm. Maybe this is something you could consider.
>
> - C
>
This archive was generated by hypermail 2.0.0 : Mon Mar 27 2006 - 01:37:49 EST