cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Menard <kmen...@servprise.com>
Subject Re: generics and ObjectContext
Date Tue, 20 Nov 2007 18:39:33 GMT
Generally I like the idea.  The fewer casts I have to make in my code
afterward, the happier I am.  Although, as is, I can make an unchecked
assignment and forego the cast anyway.

I think you'll run into issues with a few other queries as well, such as
NamedQuery and ObjectIdQuery.  I guess you could require a new class
parameter for them, but it wouldn't be backward compatible.  Likewise, you
could force a cast if they're used anonymously, but it's the same problem
you're trying to fix, just in a different place.


On 11/20/07 12:02 PM, "Andrus Adamchik" <andrus@objectstyle.org> wrote:

> Now that we have a method like this in ObjectContext:
> 
>     <T> T newObject(Class<T> persistentClass)
> 
> It is tempting to do this as well:
> 
>     List<T> performQuery(Query<T> query);
> 
> Unfortunately since the same query can be configured to return either
> objects or DataRows, a fixed definition of "Query<T>" is not
> possible. At least not with the current query API. Wonder if we
> should deprecate "setFetchingDataRows(boolean)" and instead use query
> wrappers for DataRow support. E.g.:
> 
>     SelectQuery<Artist> q = new SelectQuery(Artist.class);
>     SelectQuery<DataRow> q1 = q.createDataRowQuery();
> 
> 
> Thoughts?
> 
> Andrus
> 

-- 
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com              +1 508.892.3823 x308


Mime
View raw message