[infinispan-dev] a dsl prototype for querying infinispan

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] a dsl prototype for querying infinispan

Adrian Nistor
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")
      &nb! sp; & nbsp;   .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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] a dsl prototype for querying infinispan

Galder Zamarreno
I made some small comments directly in the commit [1] (easier to comment on individual queries…)

Overall it looks good to me :)

[1] https://github.com/anistor/infinispan/commit/c4e7a6049790f41016d20e73152fd353ce53b051

On Jun 7, 2013, at 5:56 PM, Adrian Nistor <[hidden email]> 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.
> <Mail Attachment.png>
>       // a typesafe version
>      
> User $user = $(User.class);
>       Query q0 = from($user)
>             .having($user.getName()).eq("John")
>       &nb!
>  sp; &
> nbsp;  
> .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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
[hidden email]
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] a dsl prototype for querying infinispan

Emmanuel Bernard
In reply to this post by Adrian Nistor
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] a dsl prototype for querying infinispan

Emmanuel Bernard
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] a dsl prototype for querying infinispan

Sanne Grinovero-2

wish: please try them in Eclipse too as sometimes the usage experience is not the same.

On 12 Jun 2013 18:05, "Emmanuel Bernard" <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] a dsl prototype for querying infinispan

Emmanuel Bernard

On 12 juin 2013, at 18:07, Sanne Grinovero <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> wrote:


On 12 juin 2013, at 18:07, Sanne Grinovero <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev