polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: Querying?
Date Sun, 27 Sep 2015 10:36:55 GMT
Hey Kent,

See my comments below

Kent Sølvsten a écrit :
> Just wondering ....
> We use a Module/QueryBuilderFactory to create a QueryBuilder - during
> the process we fetch an (unused) EntityFinder
> Then we use a (Module)UnitOfWork (typically of the same module??) to
> create a Query - The Query has a (wrapped) reference to the
> (Module)UnitOfWork.
> When the Query is executed, the (Module)UnitOfWork is used to lookup an
> EntityFinder and to convert EntityReferences to entities.
> Not all types of queries are supported by all indexers (EntityFinder's)
> - This means we are able to construct invalid queries.
> What I think we should do is to let the indexer itself be responsible
> for instantiating the QueryBuilder/Query - allowing better validation on
> query creation and possibly allow for better API support for native
> (solr/SPARQL/serql/SQL queries) - maybe facilitate custom API's such as
> spatial queries?
> Plain and simple encapsulation.
> This would be simple to implement IF we require that the module used for
> creating the QueryBuilder is the same as the Module-in-ModuleUnitOfWork
> used to create the query.
> We could simply move the QueryBuilderFactory from Module to
> (Module)UnitOfWork.
> But .... would it be an unreasonable restriction to collapse those?
> /module.currentUnitOfWork().newQueryBuilder(MyEntity.class).where(...).newQuery().orderBy(...).find();
> /
> It will in principle remove "functionality" - And i am not able to
> figure out if that will have any real significance in this case.

I like the idea to move QueryBuilder/Query creation to SPI, surely with
some support code, so that we can aim at better/extensible query api.
One one hand, I looked at some applications code and I always create
QueryBuilder and Query from the very same module.
On the other hand, I think we should, as Niclas suggested before, make
the visibility algorithm a first class citizen so it is better
identified and easier to grasp. Maybe doing this would help us drawing
better use cases.

> A couple of thoughts down the road:
> - I actually think that the QueryFactory should be more like a pluggable
> "service"/UOW-extension - maybe a UOW-scoped service
> That is a discussion for another day, but i think the change sketched
> above would be a suitable first step.
> - It could be interesting to toy with the idea of Query(Builder) as a
> java8-stream - since most operations on Query/QueryBuilder are very
> similar to the features of a stream
> Again, I think the change above would be a nice first step (by softening
> up the distinction between the 2 interfaces)
> The QueryExpressions are already based on Predicates, simply begging to
> be used in Stream#filter.  :-)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message