In the dawn of Cayenne we had this (IIRC offline) discussion with Andriy. The point he made was that "expression" is abstract, while "qualifier" is an expression attached to a query. I.e. "qualifier" is a name of the query attribute that happens to be an expression.
I accepted this logic back then, but then and now I am neutral to either flavor of naming. Andrus On Jan 29, 2012, at 5:10 PM, Michael Gentry wrote: > Am I the only one that finds andQualifier(Expression), > orQualifier(Expression), setQualifier(Expression), and Expression > getQualifier() to be odd? > > Qualifiers came out of WebObjects, but Cayenne uses Expression. Seems > to me those should be andExpression(Expression) ... > > mrg > > > On Fri, Jan 27, 2012 at 9:13 AM, Andrus Adamchik <[email protected]> > wrote: >> More on this topic - I usually don't use SelectQuery(..., Expression) >> constructor, as chaining Expressions is much more clunky than using >> query.andQualifier(..) / query.orQualifier(..). The only case is nested >> expressions whose parts can't be simply appended to the query. >> >> Andrus >> >> On Jan 27, 2012, at 5:06 PM, Michael Gentry wrote: >> >>> Chainable was kind of an afterthought. I mentioned limits because Ari >>> did. Basically I've been creating a lot of queries lately and then >>> after creating them, adding the ordering separately. Just seemed a >>> tad clunkier that way, so I was trying to think of ways to make it a >>> bit cleaner. >>> >>> Thanks, >>> >>> mrg >>> >>> >>> On Fri, Jan 27, 2012 at 8:51 AM, Andrus Adamchik <[email protected]> >>> 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? >>>> >>>> Andrus >>>> >>>> >>>> On Jan 27, 2012, at 4:38 PM, Michael Gentry wrote: >>>> >>>>> My only quibble with order() is it sounds immediate. Maybe orderBy() >>>>> instead? For fetch limits, could have a limitTo() method? >>>>> >>>>> Thanks, >>>>> >>>>> mrg >>>>> >>>>> >>>>> On Fri, Jan 27, 2012 at 2:11 AM, Andrus Adamchik <[email protected]> >>>>> wrote: >>>>>> IMO all of the suggestions are good. Summarizing: >>>>>> >>>>>> 1. SelectQuery(Class<?>, Expression) becomes an equivalent >>>>>> SelectQuery(Class<?>, Expression, Ordering...) >>>>>> 2. (new) SelectQuery(Class<?>, Expression, List<Ordering>) >>>>>> 3. (new) SelectQuery order(String, SortOrder) >>>>>> 4. (new) SelectQuery order(Ordering... ordering) >>>>>> 5. (new) SelectQuery order(List<Ordering> orderings) >>>>>> >>>>>> 6. (deprecated) void addOrdering / addOrderings >>>>>> >>>>>> On Jan 27, 2012, at 4:02 AM, Aristedes Maniatis wrote: >>>>>> >>>>>>> On 27/01/12 4:15 AM, Michael Gentry wrote: >>>>>>>> Any thoughts on updating SelectQuery.java to handle Orderings as: >>>>>>>> >>>>>>>> SelectQuery(Class, Expression, Ordering) or >>>>>>>> SelectQuery(Class, Expression, List<Ordering>) or >>>>>>>> SelectQuery(Class, Expression, Ordering...) or >>>>>>>> public SelectQuery addOrdering(Ordering ordering) and >>>>>>>> public SelectQuery addOrderings(List<Ordering> orderings) ... >>>>>>>> >>>>>>>> I'm personally thinking the last, so it is chainable. >>>>>>> >>>>>>> Purely from a naming point of view, both of these: >>>>>>> >>>>>>> public SelectQuery order(Ordering ordering) >>>>>>> public SelectQuery order(List<Ordering> orderings) >>>>>>> >>>>>>> This is then chainable, and will read very nicely, particularly when >>>>>>> combined with similar functions for "limit", "join/prefetch", etc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ari >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --------------------------> >>>>>>> Aristedes Maniatis >>>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >>>>>>> >>>>>> >>>>> >>>> >>> >> >
