You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2007/11/20 18:02:44 UTC
generics and ObjectContext
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
Re: generics and ObjectContext
Posted by Kevin Menard <km...@servprise.com>.
Yeah, at that point I think the law of diminishing returns kicks in. I'm a
fan of making things generic really only where they make sense. newObject()
is a perfect example.
On 11/20/07 2:34 PM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
>
> On Nov 20, 2007, at 7:02 PM, Andrus Adamchik wrote:
>
>> SelectQuery<Artist> q = new SelectQuery(Artist.class);
>
> And the correct form of the query above (if we are to parameterize
> Query interface) will look like this:
>
> SelectQuery<Artist> q = new SelectQuery<Artist>(Artist.class);
>
> So from now on all queries will have to be instantiated with <class>,
> even non-selecting ones, making things extra verbose and
> redundant ... generics really suck :-/ I may ditch the idea about the
> query parameter.
>
> Andrus
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
Re: generics and ObjectContext
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 20, 2007, at 7:02 PM, Andrus Adamchik wrote:
> SelectQuery<Artist> q = new SelectQuery(Artist.class);
And the correct form of the query above (if we are to parameterize
Query interface) will look like this:
SelectQuery<Artist> q = new SelectQuery<Artist>(Artist.class);
So from now on all queries will have to be instantiated with <class>,
even non-selecting ones, making things extra verbose and
redundant ... generics really suck :-/ I may ditch the idea about the
query parameter.
Andrus
Re: generics and ObjectContext
Posted by Robert Zeigler <ro...@puregumption.com>.
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 <mc...@gmail.com>
>> ISI.NC
>>
>
Re: generics and ObjectContext
Posted by Kevin Menard <km...@servprise.com>.
I have mixed feelings on that one. Seems like too much code to change.
But, maybe it should be expected.
Like I said, I loved getting rid of all my casts with newObject(). But, at
the same time, I had to add a lot more because performQuery() now returns
List<?> rather than List. Before I was okay with the unchecked access, but
now that's not possible for better or worse. In any event, a cast is nearly
always required because retrieving items from a List<?> is going to require
such.
On 11/20/07 3:16 PM, "Andrus Adamchik" <an...@objectstyle.org> 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
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
Re: generics and ObjectContext
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <mc...@gmail.com>
> ISI.NC
>
Re: generics and ObjectContext
Posted by Mikaël Cluseau <mi...@isinc.dyndns.org>.
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 <mc...@gmail.com>
ISI.NC
Re: generics and ObjectContext
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 20, 2007, at 9:11 PM, Andrus Adamchik wrote:
>
>> 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.
>
> I guess any query that does not take a class (SelectQuery may also
> be entity-name based) would be Query<?>, resulting in List<?>
> returned.
Since I am still not fluent with generics, I may have made a wrong
assumption here. Actually you can do this:
NamedQuery<Artist> q = new NamedQuery<Artist>("X");
List<Artist> l = context.performQuery(q);
This won't provide any extra type safety of course, only an
indication of the result type.
Andrus
Re: generics and ObjectContext
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 20, 2007, at 8:39 PM, Kevin Menard wrote:
> 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.
I guess any query that does not take a class (SelectQuery may also be
entity-name based) would be Query<?>, resulting in List<?> returned.
Andrus
Re: generics and ObjectContext
Posted by Kevin Menard <km...@servprise.com>.
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" <an...@objectstyle.org> 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