<p dir="ltr">wish: please try them in Eclipse too as sometimes the usage experience is not the same. </p>
<div class="gmail_quote">On 12 Jun 2013 18:05, "Emmanuel Bernard" <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
That is also why thinking about all possible future needs is important.<br>
<br>
Emmanuel<br>
<br>
On 12 juin 2013, at 17:44, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>
<br>
> A few comments in no particular order<br>
><br>
> - nice work<br>
> - try and cover all future possible extensions of the language to be<br>
> sure you are not heading to a trap<br>
> - no cross type support<br>
> I suspect some kind of Union query could be useful<br>
> (from(User.class)....union().from(Dog.class)...)<br>
> - projection<br>
> you must think about projection and aggregation from day one even if<br>
> you end up not offering it initially.<br>
> - I'm skeptical about contains* as I don't see much value in them as<br>
> they seem quite specific. Do they work beyond collection of native<br>
> types?<br>
> - I can't see how you will write complex predicate compositions (nested<br>
> ands and ors) while keeping your elegant flow.<br>
> I suspect you need some external reference? From where?<br>
> That's usually where these styles of fluent APIs wo params fall<br>
> apart and why we went differently in JPA.<br>
> - static method entry point<br>
> I suspect that using a static method entry point is a mistake.<br>
> Yes it looks simpler and more elegant than qb.from() but you also lose<br>
> any ability to have a context passed and used during the query<br>
> construction (like the CacheManager or whatever).<br>
> I could be wrong though as I haven't seen how you will execute the<br>
> query.<br>
><br>
> Emmanuel<br>
><br>
> On Fri 2013-06-07 18:56, Adrian Nistor wrote:<br>
>> Hi all,<br>
>><br>
>> As per ISPN-3169 "Define a Query API that will be common for library<br>
>> mode + remote" we set out to define a simple dsl for writing queries<br>
>> against embedded and remote caches that should be agnostic to the<br>
>> actual engine that executes the query (lucene in our case now but<br>
>> might be others later) and yet be easy to be translated into the<br>
>> native query language of the said engine.<br>
>><br>
>> Our dsl aims to support filtering cached entities:<br>
>> * by attributes allowing equality and range filters (less than,<br>
>> greater than, between)<br>
>> * some very simple collections tests (contains(value),<br>
>> containsAll(setOfValues), containsAny(setOfValues)) that can be<br>
>> applied to attributes that are collections of values<br>
>> * string 'like' operator similar to SQL<br>
>> * 'in' filter, to test if the attribute value belongs to a given<br>
>> fixed set of values<br>
>> * The filters can be composed of subfilters connected by logical<br>
>> and/or operators. Operator precedence can be changed using nested<br>
>> subfilters.<br>
>> * Negation is also allowed of course<br>
>> * besides filtering based on attributes of the root entity it<br>
>> should also be able to filter on attributes of embedded entities<br>
>> (eg. person.address.postalCode == "123") at any nesting level<br>
>><br>
>> As for type safety, the dsl should not allow the user to build<br>
>> syntactically invalid queries.<br>
>> Having a dsl that is also typesafe with regard to the domain model<br>
>> is desirable, but not a must for this early stage.<br>
>><br>
>> Here is a simple domain model I've used for writing some sample queries.<br>
>><br>
>> // a typesafe version User $user = $(User.class);<br>
>> Query q0 = from($user)<br>
>> .having($user.getName()).eq("John")<br>
>> .and()<br>
>> .having($user.getAddress().getPostCode()).eq("NW123")<br>
>> .build(); // non typesafe field references<br>
>> Query q1 = from(User.class)<br>
>> .having("name").eq("John")<br>
>> .and()<br>
>> .having("surname").eq("Doe")<br>
>> .build(); More query samples on github here:<br>
>> <a href="https://github.com/anistor/infinispan/blob/t_3169_m/query/src/main/java/org/infinispan/query/sandbox/sample_domain_model/QuerySamples.java" target="_blank">https://github.com/anistor/infinispan/blob/t_3169_m/query/src/main/java/org/infinispan/query/sandbox/sample_domain_model/QuerySamples.java</a><br>
>> This is just an interface sketch, not an implementation. Your<br>
>> thoughts and comments regarding this dsl are very welcome! I'll add<br>
>> all of the above to the wiki too. Cheers<br>
><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div>