You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2007/06/05 16:10:47 UTC
Re: performing count
[taking to dev]
There was an old QueryUtils class that was used for some internal
obscure queries. It's long gone (don't even remember which version
dumped it). So now we can reuse the name for the user-friendly
utility class (if we decide to go this way).
Andrus
On Jun 5, 2007, at 4:54 PM, Michael Gentry wrote:
> Hasn't QueryUtils gone poof in 3.0?
>
> /dev/mrg
>
>
> On 6/5/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> So where do we put it then? QueryUtils?
>>
>> Andrus
>>
>>
Re: What a query result can be [Was: performing count]
Posted by Michael Gentry <bl...@gmail.com>.
I was thinking that, too ... seemed to stick in the back of my brain from
when I added the enumeration stuff. Made things harder. Static methods are
really functions, but are being marketed as methods. :-)
/dev/mrg
On 6/22/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Unfortunately there's no static method inheritance in Java :-/
>
> Andrus
>
>
Re: What a query result can be [Was: performing count]
Posted by Andrus Adamchik <an...@objectstyle.org>.
Unfortunately there's no static method inheritance in Java :-/
Andrus
On Jun 22, 2007, at 3:32 PM, Michael Gentry wrote:
> What if we put that bit of code in CayenneDataObject as a static
> method?
> Then you could say something like:
>
> Number count = Artist.numberOfRecordsInDatabase();
>
> I suppose it could return an int, too. I always get confused about
> inheritance rules with static methods, though (would it know it was an
> Artist instead of CayenneDataObject so it could look up the
> appropriate
> table information?). I'd have to go do a little test case.
> (Strangely, I
> know how it works in Objective-C.)
>
> Another "interesting" thought is what about inheritance? Could:
>
> Number count = Manager.numberOfRecordsInDatabase();
>
> automatically add the inheritance qualifier for the Manager object?
>
> Thanks,
>
> /dev/mrg
>
>
> On 6/22/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> Just added another JPA extension to Cayenne Classic - a mechanism to
>> return scalars from SQLTemplate. Let me demonstrate how this works.
>> Take a normal query execution example:
>>
>> List results = context.performQuery(query);
>>
>> * In Cayenne Classic each element in the "results" list is either a
>> Persistent or a DataRow.
>> * In JPA each element is either a Persistent or a scalar (such as
>> java.lang.Integer), or an Object[] containing a mix of the previous
>> two types.
>>
>> So the JPA difference is that (a) scalars are first-class citizens as
>> far as query result is concerned; (b) multiple scalar/objects per row
>> can be a part of the same result; [(c) no concept of DataRow, but
>> that's not relevant for this discussion].
>>
>>
>> So what I did now is adding support for scalars and arrays of scalars
>> to the "raw" queries. So now a count can be done as SQLTemplate in a
>> following manner:
>>
>> // a bit involved query construction procedure
>> String sql = "SELECT count(1) AS C FROM ARTIST";
>> SQLTemplate query = new SQLTemplate(Artist.class, sql);
>> query.setColumnNamesCapitalization
>> (SQLTemplate.UPPERCASE_COLUMN_NAMES);
>>
>> SQLResultSetMapping rsMap = new SQLResultSetMapping();
>> rsMap.addColumnResult("C");
>> query.setResultSetMapping(rsMap);
>>
>> // very simple scalar result set retrieval
>> Number count = (Number) DataObjectUtils.objectForQuery(context,
>> query);
>>
>>
>> We can hide SQLTemplate creation internals inside a CountQuery, but a
>> user can easily take care of result processing without extra utility
>> API (see the last line in the code above - no need to unwrap a Map or
>> anything).
>>
>> Regarding the earlier concern that DataObjectUtils is dealing with
>> non-DataObjects, looks like a conceptual shift of "what a query
>> result is" solves that as well. Now we consider any
>> "java.lang.Object" a valid result, only some objects are persistent
>> and have identity, and others - do not. Comments?
>>
>> Andrus
>>
>>
Re: What a query result can be [Was: performing count]
Posted by Michael Gentry <bl...@gmail.com>.
What if we put that bit of code in CayenneDataObject as a static method?
Then you could say something like:
Number count = Artist.numberOfRecordsInDatabase();
I suppose it could return an int, too. I always get confused about
inheritance rules with static methods, though (would it know it was an
Artist instead of CayenneDataObject so it could look up the appropriate
table information?). I'd have to go do a little test case. (Strangely, I
know how it works in Objective-C.)
Another "interesting" thought is what about inheritance? Could:
Number count = Manager.numberOfRecordsInDatabase();
automatically add the inheritance qualifier for the Manager object?
Thanks,
/dev/mrg
On 6/22/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Just added another JPA extension to Cayenne Classic - a mechanism to
> return scalars from SQLTemplate. Let me demonstrate how this works.
> Take a normal query execution example:
>
> List results = context.performQuery(query);
>
> * In Cayenne Classic each element in the "results" list is either a
> Persistent or a DataRow.
> * In JPA each element is either a Persistent or a scalar (such as
> java.lang.Integer), or an Object[] containing a mix of the previous
> two types.
>
> So the JPA difference is that (a) scalars are first-class citizens as
> far as query result is concerned; (b) multiple scalar/objects per row
> can be a part of the same result; [(c) no concept of DataRow, but
> that's not relevant for this discussion].
>
>
> So what I did now is adding support for scalars and arrays of scalars
> to the "raw" queries. So now a count can be done as SQLTemplate in a
> following manner:
>
> // a bit involved query construction procedure
> String sql = "SELECT count(1) AS C FROM ARTIST";
> SQLTemplate query = new SQLTemplate(Artist.class, sql);
> query.setColumnNamesCapitalization
> (SQLTemplate.UPPERCASE_COLUMN_NAMES);
>
> SQLResultSetMapping rsMap = new SQLResultSetMapping();
> rsMap.addColumnResult("C");
> query.setResultSetMapping(rsMap);
>
> // very simple scalar result set retrieval
> Number count = (Number) DataObjectUtils.objectForQuery(context,
> query);
>
>
> We can hide SQLTemplate creation internals inside a CountQuery, but a
> user can easily take care of result processing without extra utility
> API (see the last line in the code above - no need to unwrap a Map or
> anything).
>
> Regarding the earlier concern that DataObjectUtils is dealing with
> non-DataObjects, looks like a conceptual shift of "what a query
> result is" solves that as well. Now we consider any
> "java.lang.Object" a valid result, only some objects are persistent
> and have identity, and others - do not. Comments?
>
> Andrus
>
>
What a query result can be [Was: performing count]
Posted by Andrus Adamchik <an...@objectstyle.org>.
Just added another JPA extension to Cayenne Classic - a mechanism to
return scalars from SQLTemplate. Let me demonstrate how this works.
Take a normal query execution example:
List results = context.performQuery(query);
* In Cayenne Classic each element in the "results" list is either a
Persistent or a DataRow.
* In JPA each element is either a Persistent or a scalar (such as
java.lang.Integer), or an Object[] containing a mix of the previous
two types.
So the JPA difference is that (a) scalars are first-class citizens as
far as query result is concerned; (b) multiple scalar/objects per row
can be a part of the same result; [(c) no concept of DataRow, but
that's not relevant for this discussion].
So what I did now is adding support for scalars and arrays of scalars
to the "raw" queries. So now a count can be done as SQLTemplate in a
following manner:
// a bit involved query construction procedure
String sql = "SELECT count(1) AS C FROM ARTIST";
SQLTemplate query = new SQLTemplate(Artist.class, sql);
query.setColumnNamesCapitalization
(SQLTemplate.UPPERCASE_COLUMN_NAMES);
SQLResultSetMapping rsMap = new SQLResultSetMapping();
rsMap.addColumnResult("C");
query.setResultSetMapping(rsMap);
// very simple scalar result set retrieval
Number count = (Number) DataObjectUtils.objectForQuery(context,
query);
We can hide SQLTemplate creation internals inside a CountQuery, but a
user can easily take care of result processing without extra utility
API (see the last line in the code above - no need to unwrap a Map or
anything).
Regarding the earlier concern that DataObjectUtils is dealing with
non-DataObjects, looks like a conceptual shift of "what a query
result is" solves that as well. Now we consider any
"java.lang.Object" a valid result, only some objects are persistent
and have identity, and others - do not. Comments?
Andrus
On Jun 6, 2007, at 4:15 PM, Michael Gentry wrote:
> I don't mind resurrecting QueryUtils, but is a count method the
> only thing
> that would go in it?
>
> Thanks,
>
> /dev/mrg
>
>
> On 6/5/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> [taking to dev]
>>
>> There was an old QueryUtils class that was used for some internal
>> obscure queries. It's long gone (don't even remember which version
>> dumped it). So now we can reuse the name for the user-friendly
>> utility class (if we decide to go this way).
>>
>> Andrus
>>
>>
>> On Jun 5, 2007, at 4:54 PM, Michael Gentry wrote:
>>
>> > Hasn't QueryUtils gone poof in 3.0?
>> >
>> > /dev/mrg
>> >
>> >
>> > On 6/5/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>> >>
>> >> So where do we put it then? QueryUtils?
>> >>
>> >> Andrus
>> >>
>> >>
>>
>>
RE: performing count
Posted by Kevin Menard <km...@servprise.com>.
I see no problem supporting other aggregates as Lachlan had done in his
code snippet on the user list.
--
Kevin
> -----Original Message-----
> From: Michael Gentry [mailto:blacknext@gmail.com]
> Sent: Wednesday, June 06, 2007 10:15 AM
> To: dev@cayenne.apache.org
> Subject: Re: performing count
>
> I don't mind resurrecting QueryUtils, but is a count method
> the only thing that would go in it?
>
> Thanks,
>
> /dev/mrg
Re: performing count
Posted by Michael Gentry <bl...@gmail.com>.
I don't mind resurrecting QueryUtils, but is a count method the only thing
that would go in it?
Thanks,
/dev/mrg
On 6/5/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> [taking to dev]
>
> There was an old QueryUtils class that was used for some internal
> obscure queries. It's long gone (don't even remember which version
> dumped it). So now we can reuse the name for the user-friendly
> utility class (if we decide to go this way).
>
> Andrus
>
>
> On Jun 5, 2007, at 4:54 PM, Michael Gentry wrote:
>
> > Hasn't QueryUtils gone poof in 3.0?
> >
> > /dev/mrg
> >
> >
> > On 6/5/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> >>
> >> So where do we put it then? QueryUtils?
> >>
> >> Andrus
> >>
> >>
>
>