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
This archive was generated by hypermail 2.0.0 : Sun Jan 13 2008 - 06:57:31 EST