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" <andru..bjectstyle.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
This archive was generated by hypermail 2.0.0 : Tue Nov 20 2007 - 13:40:09 EST