I am glad that the API evolution doesn't stop and is not waiting for this or
that "big thing" to happen. The new ordering methods might become available
before we take our time to design the new query. The new vararg/generics
ObjectContext methods are already available, even though we haven't figured out
generic queries yet, etc. This makes Cayenne better now and not later.
But at some point we'll have to take on that big thing - a generics-friendly
selecting query combining features of EJBQLQuery and SelectQuery, that can be
created from String or via API, with API being chainable.
For me - I need to finish 3.1 docs and release 3.1... I'd think we can do it in
3.2 then.
Andrus
On Jan 28, 2012, at 12:38 PM, Aristedes Maniatis wrote:
> On 28/01/12 12:51 AM, Andrus Adamchik wrote:
>>> My only quibble with order() is it sounds immediate. Maybe orderBy()
>>> instead?
>>
>> Fine with me.
>>
>>> For fetch limits, could have a limitTo() method?
>>
>> FetchLimit is a bit different - it a "property" in a Java beans sense. The
>> ordering API changes do not affect the "property" aspect of it. So what is
>> the goal here, to provide chainable API?
>
> Personally I like it. I think I mentioned Ruby/Rails before, and their
> chainable query API is very succinct and readable. Now Java is naturally more
> verbose than Ruby as a language, but I like the sort of chainable api that
> looks something like this:
>
> List artists<Artist> = SelectQuery(Artist.class).where("name LIKE
> 'b%').and('age >
> 23').join(Gallery.class).limit(10).order(Artist.name).perform();
>
> We've had this conversation before, and I guess it really needs one of us to
> write up the full class API for what this sort of approach would look like if
> it is ever going to get past these conversations. I'd love if I had more time
> to sit down and think about this, but realistically that isn't soon.
>
> Regards
>
> Ari
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
