Hi all, As per ISPN-3169 "Define a Query API that will be common for library mode + remote" we set out to define a simple dsl for writing queries against embedded and remote caches that should be agnostic to the actual engine that executes the query (lucene in our case now but might be others later) and yet be easy to be translated into the native query language of the said engine. Our dsl aims to support filtering cached entities: * by attributes allowing equality and range filters (less than, greater than, between) * some very simple collections tests (contains(value), containsAll(setOfValues), containsAny(setOfValues)) that can be applied to attributes that are collections of values * string 'like' operator similar to SQL * 'in' filter, to test if the attribute value belongs to a given fixed set of values * The filters can be composed of subfilters connected by logical and/or operators. Operator precedence can be changed using nested subfilters. * Negation is also allowed of course * besides filtering based on attributes of the root entity it should also be able to filter on attributes of embedded entities (eg. person.address.postalCode == "123") at any nesting level As for type safety, the dsl should not allow the user to build syntactically invalid queries. Having a dsl that is also typesafe with regard to the domain model is desirable, but not a must for this early stage. Here is a simple domain model I've used for writing some sample queries. // a typesafe version User $user = $(User.class); Query q0 = from($user) .having($user.getName()).eq("John") .and() .having($user.getAddress().getPostCode()).eq("NW123") .build(); // non typesafe field references Query q1 = from(User.class) .having("name").eq("John") .and() .having("surname").eq("Doe") .build(); More query samples on github here: https://github.com/anistor/infinispan/blob/t_3169_m/query/src/main/java/o... This is just an interface sketch, not an implementation. Your thoughts and comments regarding this dsl are very welcome! I'll add all of the above to the wiki too. Cheers

_______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I forgot to say that fluent APIs in java are awesome but a nightmare to maintain backward compatibility wise. If you think building was hard, wait till you have to fix it or retrofit it. That is also why thinking about all possible future needs is important. Emmanuel On 12 juin 2013, at 17:44, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > A few comments in no particular order > > - nice work > - try and cover all future possible extensions of the language to be > sure you are not heading to a trap > - no cross type support > I suspect some kind of Union query could be useful > (from(User.class)....union().from(Dog.class)...) > - projection > you must think about projection and aggregation from day one even if > you end up not offering it initially. > - I'm skeptical about contains* as I don't see much value in them as > they seem quite specific. Do they work beyond collection of native > types? > - I can't see how you will write complex predicate compositions (nested > ands and ors) while keeping your elegant flow. > I suspect you need some external reference? From where? > That's usually where these styles of fluent APIs wo params fall > apart and why we went differently in JPA. > - static method entry point > I suspect that using a static method entry point is a mistake. > Yes it looks simpler and more elegant than qb.from() but you also lose > any ability to have a context passed and used during the query > construction (like the CacheManager or whatever). > I could be wrong though as I haven't seen how you will execute the > query. > > Emmanuel > > On Fri 2013-06-07 18:56, Adrian Nistor wrote: >> Hi all, >> >> As per ISPN-3169 "Define a Query API that will be common for library >> mode + remote" we set out to define a simple dsl for writing queries >> against embedded and remote caches that should be agnostic to the >> actual engine that executes the query (lucene in our case now but >> might be others later) and yet be easy to be translated into the >> native query language of the said engine. >> >> Our dsl aims to support filtering cached entities: >> * by attributes allowing equality and range filters (less than, >> greater than, between) >> * some very simple collections tests (contains(value), >> containsAll(setOfValues), containsAny(setOfValues)) that can be >> applied to attributes that are collections of values >> * string 'like' operator similar to SQL >> * 'in' filter, to test if the attribute value belongs to a given >> fixed set of values >> * The filters can be composed of subfilters connected by logical >> and/or operators. Operator precedence can be changed using nested >> subfilters. >> * Negation is also allowed of course >> * besides filtering based on attributes of the root entity it >> should also be able to filter on attributes of embedded entities >> (eg. person.address.postalCode == "123") at any nesting level >> >> As for type safety, the dsl should not allow the user to build >> syntactically invalid queries. >> Having a dsl that is also typesafe with regard to the domain model >> is desirable, but not a must for this early stage. >> >> Here is a simple domain model I've used for writing some sample queries. >> >> // a typesafe version User $user = $(User.class); >> Query q0 = from($user) >> .having($user.getName()).eq("John") >> .and() >> .having($user.getAddress().getPostCode()).eq("NW123") >> .build(); // non typesafe field references >> Query q1 = from(User.class) >> .having("name").eq("John") >> .and() >> .having("surname").eq("Doe") >> .build(); More query samples on github here: >> https://github.com/anistor/infinispan/blob/t_3169_m/query/src/main/java/o... >> This is just an interface sketch, not an implementation. Your >> thoughts and comments regarding this dsl are very welcome! I'll add >> all of the above to the wiki too. Cheers > >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Hehe yes http://emmanuelbernard.com/blog/2013/05/28/autocompletion-is-crap/ On 12 juin 2013, at 18:07, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > wish: please try them in Eclipse too as sometimes the usage experience is not the same. > > On 12 Jun 2013 18:05, "Emmanuel Bernard" <emmanuel(a)hibernate.org&gt; wrote: >> I forgot to say that fluent APIs in java are awesome but a nightmare to maintain backward compatibility wise. If you think building was hard, wait till you have to fix it or retrofit it. >> >> That is also why thinking about all possible future needs is important. >> >> Emmanuel >> >> On 12 juin 2013, at 17:44, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> >> > A few comments in no particular order >> > >> > - nice work >> > - try and cover all future possible extensions of the language to be >> > sure you are not heading to a trap >> > - no cross type support >> > I suspect some kind of Union query could be useful >> > (from(User.class)....union().from(Dog.class)...) >> > - projection >> > you must think about projection and aggregation from day one even if >> > you end up not offering it initially. >> > - I'm skeptical about contains* as I don't see much value in them as >> > they seem quite specific. Do they work beyond collection of native >> > types? >> > - I can't see how you will write complex predicate compositions (nested >> > ands and ors) while keeping your elegant flow. >> > I suspect you need some external reference? From where? >> > That's usually where these styles of fluent APIs wo params fall >> > apart and why we went differently in JPA. >> > - static method entry point >> > I suspect that using a static method entry point is a mistake. >> > Yes it looks simpler and more elegant than qb.from() but you also lose >> > any ability to have a context passed and used during the query >> > construction (like the CacheManager or whatever). >> > I could be wrong though as I haven't seen how you will execute the >> > query. >> > >> > Emmanuel >> > >> > On Fri 2013-06-07 18:56, Adrian Nistor wrote: >> >> Hi all, >> >> >> >> As per ISPN-3169 "Define a Query API that will be common for library >> >> mode + remote" we set out to define a simple dsl for writing queries >> >> against embedded and remote caches that should be agnostic to the >> >> actual engine that executes the query (lucene in our case now but >> >> might be others later) and yet be easy to be translated into the >> >> native query language of the said engine. >> >> >> >> Our dsl aims to support filtering cached entities: >> >> * by attributes allowing equality and range filters (less than, >> >> greater than, between) >> >> * some very simple collections tests (contains(value), >> >> containsAll(setOfValues), containsAny(setOfValues)) that can be >> >> applied to attributes that are collections of values >> >> * string 'like' operator similar to SQL >> >> * 'in' filter, to test if the attribute value belongs to a given >> >> fixed set of values >> >> * The filters can be composed of subfilters connected by logical >> >> and/or operators. Operator precedence can be changed using nested >> >> subfilters. >> >> * Negation is also allowed of course >> >> * besides filtering based on attributes of the root entity it >> >> should also be able to filter on attributes of embedded entities >> >> (eg. person.address.postalCode == "123") at any nesting level >> >> >> >> As for type safety, the dsl should not allow the user to build >> >> syntactically invalid queries. >> >> Having a dsl that is also typesafe with regard to the domain model >> >> is desirable, but not a must for this early stage. >> >> >> >> Here is a simple domain model I've used for writing some sample queries. >> >> >> >> // a typesafe version User $user = $(User.class); >> >> Query q0 = from($user) >> >> .having($user.getName()).eq("John") >> >> .and() >> >> .having($user.getAddress().getPostCode()).eq("NW123") >> >> .build(); // non typesafe field references >> >> Query q1 = from(User.class) >> >> .having("name").eq("John") >> >> .and() >> >> .having("surname").eq("Doe") >> >> .build(); More query samples on github here: >> >> https://github.com/anistor/infinispan/blob/t_3169_m/query/src/main/java/o... >> >> This is just an interface sketch, not an implementation. Your >> >> thoughts and comments regarding this dsl are very welcome! I'll add >> >> all of the above to the wiki too. Cheers >> > >> >> _______________________________________________ >> >> infinispan-dev mailing list >> >> infinispan-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >> > _______________________________________________ >> > infinispan-dev mailing list >> > infinispan-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev