polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Querying?
Date Thu, 24 Sep 2015 20:25:20 GMT
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.

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.  :-)

Any comments?

/Kent

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