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