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.
Andrus
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
SelectQuery<User>("User").
I think only "SelectQuery" should the parametrized, and require a
class
to be constructed.
Has the "setFetchingDataRow" been discussed ? Because
context.performQuery wouldn't return the same kind on List with the
same
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"),
.addOrder("login")
.fetch(); // or List<DataRow> [...].fetchRows();
Making Query iterable instead of using performIteratedQuery would be
better, too.
Cheers,
--
Mikaël Cluseau <[EMAIL PROTECTED]>
ISI.NC
