That's what I did in SiteVision, where each mixin was basically serialized separately and keyed by {id+class}. It works, but not necessarily that much better
You are probably right, I guess it depends on the size of each mixin. Anyway, it is probably too early to fix how the data will be partitioned.
What do You think of this design: The persistent state of an entitiy is separeted into blocks 0,1,2... Block 0 is data loaded when the entitystate is initialized. Thus the current layout is all data in block 0. Other possible layouts could be to have a separate block for each property, or lump all data together in block 1. The entitystate will need to know the partitioning model for this composite instance (probably the same for all instances of the same entity). When an attribute is loaded all data in the same block will be loaded. The data access pattern will be tracked for the current usecase.
The opens the possibility of later creating an ultrawicked cool loading policy deciding the partitioning at runtime based on usage patterns. Or just using a block per mixin. Or...
An entity is currently "loaded" in potentially 3 different steps: first the proxy is created. Then, upon first state access the EntityStore is asked for an EntityState. Then the actual state is retrieved. The EntityStore could use information about the UoW when either the EntityState or a specific property is loaded.
Which information about the UoW are You thinking of? The Usecase (not in the ES-UOW but that is easy to change)?
That in itself is not so hard, as the key will simply be the package +class+method name, i.e. QualifiedName which we already have. One issue is that if you move a property to another interface that *must* be handled or the property is "gone".
Will this not be a problem if the parts of the composites are stored individually, regardless of whether we group by class (mixin) or store each property/attribute separately (because of QN)? The problem seem to go away by using "blocks" I guess.
/Kent _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
