Hello.
On Dec 21, 2007, at 11:01 , Andrus Adamchik wrote:
> This is something I wanted to improve as well, and as you correctly
> pointed out, data rows option makes it hard...
Is it possible to reconsider the data rows flag and use a separate
class for such queries instead? We could keep the existing SelectQuery
for backward compatibility and add PersistentSelectQuery and
DataRowSelectQuery (and perhaps others for the new stuff I do not
know) that have a fixed expected query return type.
SelectQuery would be a Query<Object>
DataRowSelectQuery would be a Query<DataRow>
PersistentSelectQuery would be a Query<? extends Persistent>
Similarly, we could keep NamedQuery and introduce NamedDataRowQuery
and NamedPersistentDataRowQuery if needed.
That way, ctxt.performQuery would know what to return.
> There are a few other stumbling blocks as well, such as the new
> scalar or mixed scalar/object queries, updating queries, etc.
Is that a problem? If the query is expected to return something, it
should be possible to know something about the return type before
executing the query. Or am I way off here? I have not tried the new
scalar stuff or EJBQL Query.
> The more I think about it, the more I feel like we'll have to do
> some kind of Context/Query wrapper that supports generics
> specifically for select queries, similar to what was suggested here:
>
> https://issues.apache.org/cayenne/browse/CAY-877
A wrapper is fine, but do you think this is fixable in Query as well?
Regards,
- Tore.
This archive was generated by hypermail 2.0.0 : Fri Dec 21 2007 - 07:31:21 EST