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" <[EMAIL PROTECTED]> 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
