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.
Cheers Niclas On Mon, May 4, 2009 at 11:02 AM, Rickard Öberg <[email protected]> wrote: > Hey, > > Another method on UoW that is a bit weird is "apply". Basically it would > mean that the current event log in the UoW would be sent to the EntityStore, > then cleared, and then the user continues to do more changes, which then can > be applied, and so on. The UoW would never stop. > > But, there are some funky issues with this: > *) It would mean that the same UoW is sent to the EntityStore many times. > Since I want to use the UoW id as the id of the changelog that would mean > that several changelogs have the same id. To fix this we'd have to change id > on the UoW when we do apply(), but that doesn't feel right either. > *) If the user adds custom events to the UoW, then those would be only sent > with the first "part" of the UoW. If he really wanted them to be sent to > everything that was involved with that UoW, then they would have to be > readded to the UoW. This sounds errorprone to me. > *) When the first round of changes is sent the version of the entities > changes, so in actuality the version of the entities in the continuing UoW > should change to the new ones, so that later UoW changelogs are correct. We > would then also have to re-add "get" events to the UoW so that in effect the > UoW looks like a new one. But then the benefit of this compared to simply > creating a new one is getting hard to see. > > The two main benefits of apply() that I could see is that 1) any references > to entities would not have to be renewed. But this can be relatively easily > handled by either doing UoW.currentUnitOfWork().get(myEntityReference) > before using it, or by even allowing that to happen behind the scenes when > the Entity is used. The other is that state would be kept in the memory and > so would not have to be reloaded. But this a minor benefit, and can to some > extent be done by having decent caching on the EntityStore level. > > So... like with "refresh" I think I'm in favor of ditching apply(). > > Any opinions on this? > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
