[infinispan-dev] a dsl prototype for querying infinispan

[Emmanuel Bernard]

The reading experience is mostly unaffected though. 
Only Indentation matters. 

On 12 juin 2013, at 18:17, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Hehe yes http://emmanuelbernard.com/blog/2013/05/28/autocompletion-is-crap/
> 
> On 12 juin 2013, at 18:07, Sanne Grinovero <sanne at 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" <emmanuel at 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 <emmanuel at 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 at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >
>>> > _______________________________________________
>>> > infinispan-dev mailing list
>>> > infinispan-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130612/ca037f65/attachment-0001.html