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
