[infinispan-dev] a dsl prototype for querying infinispan

[Emmanuel Bernard]

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