On 2010-10-31 11.54, Niclas Hedhman wrote:
Three reasons;
1. In one case, the model becomes ugly since the referenced entity
doesn't need to know the referer, and I have always had the belief
that Qi4j's primary purpose is so we can stay close to the desired
model and not need to leak these kind of details.
2. Another case; It is actually many-to-many already. So although the
"right-side" (downstream) has magnitude less references back, the
additional complexity becomes significant.
3. A single hash lookup on a known field can be incredibly much
faster than the generic Indexing/Query engines. Almost all query needs
I have at this stage goes away with this feature.
Ok, fair enough. The main issue I see is that the current storage
mechanism stores these things in a blob. To handle the above properly
you'd need an EntityStore that can do it differently. Neo4j I suppose
would be a good option. I can't really think of any other options that
would scale all that well for this usecase. Any ideas?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
