The reading experience is mostly unaffected though. Only Indentation matters.
On 12 juin 2013, at 18:17, Emmanuel Bernard <emman...@hibernate.org> wrote: > Hehe yes http://emmanuelbernard.com/blog/2013/05/28/autocompletion-is-crap/ > > On 12 juin 2013, at 18:07, Sanne Grinovero <sa...@hibernate.org> 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" <emman...@hibernate.org> 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 <emman...@hibernate.org> 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/org/infinispan/query/sandbox/sample_domain_model/QuerySamples.java >>> >> 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@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 >>> >>> _______________________________________________ >>> 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
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
