Hi,
I'm now modeling quite a lot of Entities in the StreamFlow project using
Qi4j. One problem I've noticed is that since I know the implementation
strategy (for the JDBM backend), that causes me to make modeling
decisions that aren't necessarily good.
The main problem is that currently when an Entity is loaded from a
MapEntityStore (such as JDBM) 1) all data for the entity will be loaded
and 2) all properties+associations will be deserialized. Some of my
entities are getting quite a lot of properties, and some of them are
lists of complex values, if I were to do it "the right way".
But, then I will *know* that if I just want to get the Entity and read
one property, it will be very expensive. So I'm tempted to do the same
thing as EJB/Hibernate/POJO developers would do: create more entities
and reference them. But this is clearly not the right model for what I
want to achieve, just a workaround for persistence performance.
How can we fix this? One way to make the pain smaller is to simply only
deserialize properties/associations when they are actually used. Reading
the whole state of an entity should be reasonably ok, even though it may
load a lot of state that won't be used. Another way to do it is to use
key-value-stores in an entirely different way compared to now: instead
of having key-<blob> we could do
key-property/association/manyassociation. This will allow us to
read/write only the properties that are needed for a particular usecase,
and which will remove the overhead completely. The drawback is that for
usecases where you need many properties it will be more chatty towards
the key-value-store.
I know that Neo4j promotes this latter implementation, and with other
key-value stores it's up to the developer to choose model. What should
we do about this? Any insights? Can we "eat the cake and have it" in
some way???
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
