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 <andru..bjectstyle.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
>
>
This archive was generated by hypermail 2.0.0 : Fri Jun 22 2007 - 09:33:09 EDT