Niclas Hedhman wrote:
I think you may just kill my business case;
I am working on a system where you can assemble "continuous dataflow
applications" by dropping basically drawing boxes on the screen and
wire them together (each input to an output). There is a beauty in
using Entities for the "boxes" as they will end up as "lego" blocks,
each instance with its own 'configuration' (we call it parameters). A
typical 'application' would consist of 100-300 instances in memory all
the time.
IF I need to ditch the UoW when one parameter in one Entity instance
changes, it means that all my instances have to be read back from the
ES (with potentially a cache) and create the composites all over
again. Sounds very expensive to me.
Fair enough. Do you have any suggestions on how to work around the
mentioned issues? Would it be ok if apply() invalidated all the state
and did a refresh(), i.e. all entities are reloaded, but the references
are still valid.
Along the lines of previous posts on refresh(), I am here suggesting
that refresh() clear all state, reload it from entitystores, and clears
the event log. For the refresh previously used in
ConcurrentEntityModificationException we could replace that with the
suggested new operation merge().
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
