On Wed, Apr 28, 2010 at 1:09 PM, Rickard Öberg <[email protected]> wrote:
> Lazy-loading in properties in entities is implemented in the sense that the > data will not be deserialized until a property is loaded. But the data for > an entity will be loaded in full when it is accessed. However, this is an > implementation detail, and it would be entirely possible to only load parts > of an entity when accessing it, provided that you have split it up > accordingly when storing it. You don't have large collections of values in your system, so you don't see my point; Property<List<SomeValue>> values(); and the list is 15,000 elements, where I add a value regularly, but seldom access the entire thing (maybe as a nightly aggregation). Then the performance will degrade exponentially with growing of the collection. Since you seem not willing to build in timeseries support in the persistence (below) then this becomes even more useful. > That's what I did in SiteVision actually, where each mixin was stored > separately. I am not talking about large collections of individual properties, but literally large Lists and Maps of data where you continously add stuff (expensive if no explicit support for it). > Hm... maybe that now when there's no apply(), it could be done more easily. > Have to think about it. Again: what is the usecase though? You built the use-cases originally with interactive applications. > The main reason I can see history being important is actually to support > time, in the sense that Rich Hickey of Clojure describes it. If you have > entities A(v1) and B(v1) Not talking about that. But timeseries data (of course heavily influenced by my new job), where you basically provide a slider to the entire application and can set that at "23:04 24 April 2010" and look at what the snapshot state was. Building that manually is quite nasty at application level. > To handle messaging generally, on a system level, is outside our scope. That > is what ESBs like Camel and Mule does, and I would prefer to leave it to > them. Paraphrase; "To handle peristence generally, on a system level, is outside out scope. That is what ORMs , like Hibernate and OpenJPA does, and I would prefer to leave it to them." In my opinion, message-support is for large set of application as central (or more) as persistence. Being able to abstract away the mechanics from application development seems to make a LOT of sense to me, having Camel and Mule being the implementations used in the SPI extensions. Yes, the formulation of such abstraction does not exist yet, and that is where persistence was a few years ago, and I think we have done a pretty good job there. > Qi4j should deal with everything that an application developer has to deal > with. System level detail should be plugins, and is outside our scope. You are arguing against yourself. Qi4j should provide an environment where the application developer doesn't need to be concerned about system level details, and therefor part of the problems (of the app developer) that Qi4j solves for him/her. Hence inside our scope. 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
