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. * 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 ;-) Cheers Niclas On Mon, Jun 27, 2011 at 6:42 PM, Rickard Öberg <[email protected]> wrote: > Hi, > > I'm looking at the EntityFinder, both on its own, and in relation to > querying of data in general. We have talked about that sometimes one would > want to do queries over other things than just entities, such as iterables > and events, and a question is whether it is possible to tweak the > EntityFinder to handle that as well. > > AFAICT the main thing to change would be to rename it to just "Finder", and > change so that the returned type ("EntityReference") becomes a generic type, > so that it can be e.g. "EntityReference" or "Value" or "DomainEvent" etc. > The methods and exceptions would also be renamed accordingly so that they > are not entity specific. > > Then, for entities one would extend "Finder<EntityReference>" and for > searching the event-store it would be "Finder<DomainEvent>" (or somesuch). > > The last question is how to specify the dataset to apply a query to. Today > we do queryBuilder.newQuery(uow) and queryBuilder.newQuery(Iterable). If the > Finder concept is a bit more generic it would make more sense to do it the > other way round, i.e. uow.newQuery(queryBuilder), and > Iterables.newQuery(iterable,queryBuilder), or something like that. Then we > could add a EventFinder.newQuery(queryBuilder) quite easily, as well as > other services that are capable of searching. The Query concept is then not > limited to entities at all, but is mostly just a convenient way to build and > handle queries, regardless of target. This is especially true with the new > API that allows custom operators. > > One thing that is important in non-Qi4j settings is that the query can > actually return data straight, rather than having to go through entities to > load data. It would be possible to allow this by doing: > queryBuilderFactory.newQueryBuilder(SomeValue.class) > where the properties of SomeValue essentially dictate the list of "columns" > that you want to receive. The value itself becomes the projection, but > strongly typed. That could be incredibly efficient. > > These are just some ideas on how to improve the Query API. Any > thoughts/suggestions on this? > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
