On Tue, Apr 27, 2010 at 10:42 AM, Rickard Öberg <[email protected]> wrote:
> So that you can work on it while not in a UoW? I would really not encourage > this. What we do have now is that if you have an entity reference from a > completed UoW you can "renew it" by calling uow.get(entity) which will get > you the same one in the given UoW. Is that enough? Well, my problem is that I don't have the use-case, and highly speculative guess work; Entities are inherently mutable, and I like Values better. So, I think what I am fishing for is "conversion"-support between entities and values, possibly as entities->values and values->entitybuilders. >> How can we >> provide better lazy-loading support for Entitystore implementors? > > Implementing some kind of caching helper would be nice. Pretty much all > stores right now would benefit from it. Yes, I thought we had that already, and can extend it. But lazy-loading is Properties and Values is (AFAIK) not implemented, mainly due to the JSON serialization strategy, which breaks down for large (non-association) collections that are seldom accessed. So, direct support for "append" as well as "get on demand" would be great, but I know it is non-trivial. >> What >> about the earlier NestedUnitOfWork, can we sort that out? Should we? > > I would suggest that we don't do that. It messes things up too much I think. This is actually strange. If a MemoryEntityStore is created on the fly, and attached to the underlying UoW, it looks on paper very straight forward. >> + History support for Entities. Almost all apps I have ever worked on >> that use persistence, have had versioned stores. We should create the >> APIs and SPIs for this support. > > Wouldn't it be enough to support EventSourcing? Or for what purpose do you > want versioning of the state? > > I have had great use of EventSourcing, in that services can subscribe and > consume to events, but I'm not sure what to use versioned objects for. Any > thoughts on that? I don't know how to "access it", but basically at the API level be able to ask for an Entity's state at a particular point in time is what I am looking for. A built-in way for the access, which is either turned on or off. Then that would probably need support in SPI level. Why not EventSourcing? Because, although I am convinced that it is more suitable in many cases, I don't think it will be popular due to learning curve. People are really used to ORM-like models, and if that basic understanding is complemented with "Oh, I have automatic history support without effort!", I think our standing as kick-ass system will be even higher. > The EventSourcing lib I did in Streamflow could definitely be ported. But > that's for domain events, rather than system events. What are the usecases > you have in mind where Qi4j would come in? As I mentioned, a broad subject. One area is easily identifiable; There are many ways to connect separate systems with messages, synchronous, asynchronous, RPC-like or document-based and so on. Just like we abstract away the persistence, so that different implementations can be plugged in after the code is written, I think we should do the same for messaging. Loads of enterprise systems has some type of cross-system messaging (often XML (not always SOAP) over MQ), and we should tick that box in a powerful way. Then there is in-app events, where EventSourcing may (I need to look at it closer) be suitable, or may be not. Either way, my guess is that library is 'good enough' here and don't need an extension SPI. Cheers -- 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
