On 2009-10-20 07.10, Kent Sølvsten wrote:
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...
Yes, that would definitely be possible. Interesting idea!
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)?
The Usecase would be one. If it's not explicitly in the Usecase, then
the EntityStore can create information manually by "learning" what a
Usecase does.
The Usecase *is* handed to the ES when a UoW is started, so that it's
not in the default ESUOW is an implementation detail, so yes, it is easy
to change if necessary.
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.
Yeah, it might be that that's the conclusion: storing all together is
wrong (loading too much) and storing all separate is wrong (not loading
enough), so the "right" solution has to be in the middle, and the
variant using blocks seems like an ok way to do it.
Basically you would have:
Block 0: all properties/assocs/manyassocs. This is used for write-usecases.
When the EntityStore figures out that a read-usecase (=discard is used)
loaded property 1,3 and assoc 4, then it creates that as a block unless
it already exists. I.e. the key is {prop=1,3;assoc=4}, so that any other
usecase having the same access pattern can reuse it. In my own case, I
have a property "description" that is used for lots of usecases, so that
key is {prop=description} and would be used by many usecases.
When a write-usecase is performed it writes to block 0, and either
deletes all the other blocks (so that they can be created on read) or
eager-updates them within the same write.
Lots of tweaking and thinking to be done, but the basic idea seems ok to me.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
