The ones I have only return the sum/avg/count/min/max for a given query, not the original rows, too.
On Wed, Dec 3, 2014 at 2:07 AM, Andrus Adamchik <and...@objectstyle.org> wrote: > Perhaps something more integrated. I.e. an aggregate expression will be > part of a query, with an option to return the main object together with an > aggregate (more generally - with an option to customize the SELECT clause). > E.g. an equivalent of the following EJBQL which already works: > > "SELECT a, count(a.paintings) FROM a" > > Andrus > > > > On Dec 2, 2014, at 7:28 PM, Michael Gentry <mgen...@masslight.net> > wrote: > > > > Will the AggregateUtils thing I did be helpful? > > > > > > On Tue, Dec 2, 2014 at 6:12 AM, Andrus Adamchik <and...@objectstyle.org> > > wrote: > > > >> > >>> On Dec 2, 2014, at 1:51 PM, Aristedes Maniatis <a...@maniatis.org> > wrote: > >>> > >>> On 2/12/2014 7:53pm, Andrus Adamchik wrote: > >>>> > >>>>> On Dec 1, 2014, at 2:06 PM, Andrus Adamchik <and...@objectstyle.org> > >> wrote: > >>>>> > >>>>> I think I'll actually create a "stable" branch for 4.0.M2, as new > >> changes will keep coming in and we want the release to happen > >>>> > >>>> Which I just did: > >> https://github.com/apache/cayenne/tree/4.0.M2_prerelease > >>> > >>> Cool. There is a lot of great work in there. > >> > >> Yep. My app code looks so much cleaner after I migrated it to the new > >> APIs. And while still raw, the new cdbimport rules. > >> > >>> I think our previous naming regime would have this branch called > >> STABLE-4.0 if we are ready to now make trunk/head available for new work > >> that will not land into 4.0. > >> > >> I didn't give much thought to the branch naming in this instance, as I > am > >> planning to merge and delete this branch after the release (leaving the > tag > >> around of course). So it is a short-lived thing. > >> > >>> If this really is the end of all new features, then perhaps the next > >> release will be 4.0-beta1? > >> > >> There's more query API work planned. We need to align ProcedureQuery and > >> NamedQuery, and create a fluent thing for non-selecting SQLTemplates. > >> Though these can be done pretty quickly. > >> > >> A bigger project is to bring all EJBQLQuery functionality into > >> ObjectSelect - multi-result selects, aggregate queries, etc. This is > more > >> challenging. Whether this stuff should be 4.0 or say 4.1 is debatable. I > >> feel there's lots of benefit in a quick completion of 4.0. There are > users > >> who are only allowed to use "GA" tagged dependencies in their work. And > by > >> the time we get a "full solution", a few years may pass and it won't be > as > >> exciting by then :) So I am +1 on the Beta idea. > >> > >> Andrus > >
