On Dec 28, 2007, at 10:31 AM, Andrus Adamchik wrote:
> Ok, I've played a bit with parameterizing Query... The results are
> mixed at best. I am trying to avoid the explosion of subclasses
> (consider that in addition to SelectQuery we have EJBQLQuery,
> ProcedureQuery, SQLTemplate, NamedQuery, ObjectIdQuery, etc. that
> can return a ResultSet).
The underlying problem is that the fetchingDataRow flag can change the
return type of the Query. Right? Trying to look at this from an
outside view, I think the fetchingDataRow behavior is a good candidate
to be represented in separate classes instead of if-statements.
In cayenne and our projects, setFetchingDataRows(boolean) are mostly
called right after the Query constructor and almost never based on
some external (to the method calling the Query contrstructor)
information. Based on this limited code base, I guess that most users
know the return type when the Query is constructed.
> But we are still left with 6 extra subclasses that the user will
> have to deal with in the code, as well as the method naming issues
> that Ari mentioned :-/
Most users will not use that many Query types. In our project (as an
example), we only use SelectQuery and SQLTemplate query and switching
those over to typed classes will be very easy.
After making the Query infrastructure typed, the creation of a Query
can be simplified with a Factory class as some of you have mentioned.
It could be like the Collections API "Collections" or Google
Collections "Maps". That factory could then return the proper Query,
not some new non-Query(-less-usable) wrapper around a Query.
- Tore.
This archive was generated by hypermail 2.0.0 : Sun Dec 30 2007 - 15:24:24 EST