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. Cheers Niclas On Fri, Sep 25, 2015 at 4:25 AM, Kent Sølvsten <[email protected]> wrote: > 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
