Yeah, considering the rest of this thread (BTW, "setFetchingDataRow"
where mentioned at the beginning), I am also thinking along the lines
of taking generics out of ObjectContext and into some wrapper query
API, which would be either a modification of the current queries, or
indeed a wrapper along the lines of CAY-877.
On Nov 20, 2007, at 9:55 PM, MikaŽl Cluseau wrote:
> Le mardi 20 novembre 2007 ŗ 21:11 +0200, Andrus Adamchik a ťcrit :
>> I guess any query that does not take a class (SelectQuery may also be
>> entity-name based) would be Query<?>, resulting in List<?> returned.
> Query<Persistent>, indeed, since you can't put "new Query<?>()". Thus,
> someone could write about anything he wants, and I think it is a
> feature, since it allows you to say "I know what it will be". I.e. new
> I think only "SelectQuery" should the parametrized, and require a
> to be constructed.
> Has the "setFetchingDataRow" been discussed ? Because
> context.performQuery wouldn't return the same kind on List with the
> query object.
> ---- Random thoughts around that ----
> You may to consider that the query can have the "perform*" methods in
> the following way (may have been discussed in Jira, I dunno), and to
> allow chain commands :
> ObjectContext context = ...;
> List<User> results = new SelectQuery<User>(User.class)
> .andQualifier("registrationTime<?", new Date())
> .addOrder("registrationTime", "desc"),
> .fetch(); // or List<DataRow> [...].fetchRows();
> Making Query iterable instead of using performIteratedQuery would be
> better, too.
> MikaŽl Cluseau <mc.isi.n..mail.com>
This archive was generated by hypermail 2.0.0 : Tue Nov 20 2007 - 15:17:30 EST