I've done something like that in on of my recent projects.
Basically, to hide all of the casts I would normally have to make, I
wrote a static utility wrapper that would call into the cayenne
methods for me. That way, my use of "@SuppressWarnings("unchecked")"
was limited to basically just that utility class.
I've spent more than my fare share of time beating my head against
generics. Mostly I like them. Except when I hate them. :)
Cheers,
Robert
On Nov 20, 2007, at 11/202:16 PM , Andrus Adamchik wrote:
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
