Looks good to me, at high level.
This will have to focus on the capabilities of the non-indexed query
engine though, as we won't be able to expose the more advanced
capabilities over the DSL without introducing an hard dependency on
Hibernate Search.
Conversely, the method accepting an Ickle query will have to fail at
runtime if it's using full-text capabilities and the indexing engine
wasn't enabled.
I think that's fine, as it's not wildly different than attempting a
full-text query today when having the wrong fields indexed: we can
only validate such things when the query is parsed.
[N.B. I'd like to see a way to pre-register queries - like "prepared
statement", for many other good reasons so that might improve
eventually]
So the tricky part will be to cleanly separate the query API from the
full-text query API, and the downside will be that using full-text
queries will still require some form of API unwrapping.
I take it you'd like to see the same API which we'll make for Cache to
be exposed on Remote Cache ?
Thanks,
Sanne
On 20 April 2017 at 13:08, Tristan Tarrant <ttarr...@redhat.com> wrote:
> Querying an Infinispan cache is currently a bit cumbersome. There are
> two paths:
>
> Ickle:
> Search.getQueryFactory(cache).create("...").list();
>
> DSL (one possible example):
> Search.getQueryFactory(cache).from(class).[filters].build().list();
>
> Ideally we should have something like:
>
> Ickle:
> cache.query("...").list();
>
> DSL:
> cache.query(class).[filters].list();
>
> Additionally, the query module is separate from infinispan-core. While
> this made sense when we didn't have non-indexed query capabilities (and
> is somewhat mitigated by the uberjars), I feel that query should be a
> 1st class citizen API-wise.
> For this reason I propose that we extract the query API to
> infinispan-commons, put the query SPI in infinispan-core together with
> the non-indexed implementation and have the hibernate-search backend as
> a pluggable implementation.
>
> Thoughts ?
>
> Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
