Just catching up on this thread FWIW...
On 31/12/2007, at 7:23 AM, Tore Halset wrote:
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.
That sounds reasonable to me.
I also agree that the following is of no real benefit...
<T> List<T> performQuery(Class<T> aClass, Query query);
... as generics is only of use if <T> is guaranteed to be of the same
type as that of the query's entity; not just for subsequent class-
casting help. i.e., I shouldn't be able to do the following and
compile successfully...
SelectQuery query = new SelectQuery(EntityA.class);
List<EntityB> results = context.performQuery(EntityB.class, query);
with regards,
--
Lachlan Deck
