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. :-) :-) Cheers /Paul
