polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Querying?
Date Sat, 26 Sep 2015 05:41:04 GMT
You are bringing up a lot of details, and I simply don't have time to
investigate the details right now. I will try to remember to revisit this
at a later date.

One thing is known; The RDF implementation does the right thing, the SQL
implementation doesn't.

Why is that? I am not sure. But the intent is that the Query implementation
needs to take the "view position" of the caller, not its own location in
the Structure. I think this is what SQL impl is failing, and had to
introduce the hack of a type finder (can't recall the exact name).

It could be that it is this reason, why the Query impl looks complex, and I
am not able to comment on whether this can be simplified or not. I just
hope we won't do the same mistake as 2nd generation of our
Persistence/Indexing/Query system, where everything ended up "wrong" in
terms of visibility.


On Fri, Sep 25, 2015 at 4:25 AM, Kent SĂžlvsten <kent.soelvsten@gmail.com>

> 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

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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