cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: Chainable SelectQuery
Date Sun, 16 Nov 2014 13:49:43 GMT
Hi Andrus,

Perhaps I've missed the boat on this one (been too busy at work, etc),
but I think it might be more readable to not abbreviate names and
perhaps make it read more like a sentence.  Given your example,
perhaps something like:

List<Artist> artists =
  .orderBy(Artist.DATE_OF_BIRTH.ascending(), Artist.ARTIST_NAME.descending())
  .localCache("cg2", "cg1").fetch(context);

Replace "exp" with "where", "eq" with "is", "select" with "fetch"
(since it is actually fetching your records), etc.  (Choosing good
names is quite difficult -- I'm just tossing some ideas out.)

So: Create a query for Artist where name is "me", order by date of
birth (ascending), name (descending), prefetching paintings and use
local cache.  OK, fetch them into this context.

I really need to update and try the new code.



PS. Yesterday afternoon I was going through some of the JIRA issues
and saw some interesting screenshots for modeler changes where
attributes and relationships were being merged.  Quite interested in
checking that out, too.

On Sat, Nov 15, 2014 at 5:39 AM, Andrus Adamchik <> wrote:
>> On Oct 11, 2014, at 4:06 AM, Andrus Adamchik <> wrote:
>> 1. Instead of drastically redoing good old SelectQuery, we'll create a separate class
called ObjectSelect featuring fluent API. No deprecations in SelectQuery.
>> [..]
>> Also cases when you need to reset/replace previous settings. So both styles have
their use.
>> 2. Instead of "qualifier" the new query might just use "exp" (in addition to "and"
and "or").
>> 3. ExpressionFactory.exp(..) and ObjectSelect.exp(..) should allow for both named
parameter binding as well as vararg positional binding.
>> 4. Still need to come up with fluent API for orderings and prefetches. Separation
from SelectQuery should simplify this task.
>> 5. The last method in a chain doesn't have to be limited to "select" and "selectOne".
It can be query-specific, depending on what operations a given query supports. E.g. we can
have queries with "count(context)", etc. This is something we should explore.
>> 6. Corollary to #5, we should explore iterator methods in query chains (need to make
sure that we don't reinvent the wheels invented in Java 8).
>> 7. Non-selecting queries should use such API too. E.g. in addition to SQLSelect we
might have SQLOperation with chain terminating with "int update(context)" or "int[] batchUpdate(context)"
or "QueryResponse exec(context)". Same goes for ProcedureQuery.
> The new query is checked in. It supports all the options of SelectQuery (including more
exotic ones like generic query of fetching by DbEntity name), and is fully fluent. So you
can do this:
>   List<Artist> artists =
>         ObjectSelect.query(Artist.class)
>         .exp(Artist.ARTIST_NAME.eq("me"))
>         .orderBy(Artist.DATE_OF_BIRTH.asc(), Artist.ARTIST_NAME.desc())
>         .prefetch(Artist.PAINTING_ARRAY.joint())
>         .localCache("cg2", "cg1").select(context);
> or this (kinda shows why chains are cool) :
>   for(Artist a  : ObjectSelect.query(Artist.class).select(context)) {
>         ...
>   }
> or this:
>   Artist a = ObjectSelect.query(Artist.class, Artist.ARTIST_NAME.eq("me")).selectOne(context);
> Also Expression, SQLSelect and SQLTemplate now fully support positional parameters. Items
5,6,7 still need to be explored.
> Enjoy!
> Andrus

View raw message