Re: What a query result can be [Was: performing count]

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri Jun 22 2007 - 09:39:28 EDT

  • Next message: Michael Gentry: "Re: What a query result can be [Was: performing count]"

    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 <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:39:53 EDT