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.
Interrrrresting. I was actually thinking of a disjoint layout of
blocks, In Your case: block0={prop=description} (used in all
usecases), block1={prop=3;assoc=4}, block2={prop=2}, so all usecases
would load block0, the read-usecase would load block0+block1, and the
write-usecase would load block0+block1+block2.
Didn't think of the possibility to trade space for speed (letting the
same property be part of several blocks and thus having redundant
data). But of course possible and often optimal, since it will be an
implementation detail.
One issue though: I believe I have a vague idea of how to optimize for
speed based on usage patterns and performance characteristics, but
optimize for a trade-off between space and speed? I have no clue what-
so-ever :-)
/Kent
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
