On 6/29/11 15:55 , Niclas Hedhman wrote:
In general; yes, there is room for a lot of improvements in this
space. Trying to formalize your observations;
* Query is a generic concept for selection of a data subset and not
at all tied to Entities.
* Query exists in 2 major flavors, Generic and Translated. Generic
can happen on any data available in memory. Translated is passed on to
a subsystem for search in a foreign engine. For that engine to find
data, it must have been Indexed previously.
* Indexing is possibly not a Entity-only affair. If I keep a large
dataset in-memory, I should be able to keep an Index set of it up to
date.
Yes, yes, and yes.
* Query Expressions can be extended with practically any custom
operators. This leads to Translated Queries need a mechanism to
separate 'supported' operators from others, and be able to do
sub-Query in the native query engine environment and finalization of
remainder of the expression in-JVM. A hard problem to be efficient and
sounds like a student project ;-)
IMO there's going to be, initially, three flavors. Generic only,
translated only (such as .sparql("....")), and translated using
generic+custom operators (e.g.
QueryExpressions.isNotNull().and(SesameExpressions.isLiteral()).
This is reasonably manageable, without having to do what you suggest,
although that would *technically* be kind of possible, sometimes.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
