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 ..uppressWarnings("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. :)
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.
> 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
>>> entity-name based) would be Query<?>, resulting in List<?> returned.
>> Query<Persistent>, indeed, since you can't put "new Query<?>()".
>> 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.
>> 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 - 19:52:05 EST