On Dec 27, 2007, at 10:52 AM, Aristedes Maniatis wrote:
>> // existing
>> List performQuery(Query query);
>>
>> // existing
>> QueryResponse performGenericQuery(Query query);
>>
>> // new
>> <T> List<T> performQuery(Class<T> aClass, Query query);
>>
>> // new
>> List<DataRow> performDataRowQuery(Query query);
>>
>> It still makes things a bit more verbose (and redundant, as Class
>> will be specified twice - once in query constructor, and second
>> time in the context), but everything about generics is verbose and
>> redundant after all :-/ I guess after that we can deprecate
>> 'setDataRows' on SelectQuery and SQLTemplate, (as well as
>> "ObjectContext.performQuery(Query)", although we can keep this one
>> around longer as it is heavily used by everybody).
>
> Can't say I'm wild about the idea. I think if we are asking users to
> change their code in some way to suit a new API that we may as well
> design that API to survive the next 5 years without being
> embarrassed about it. I think this is one of the most used and most
> visible parts of the entire Cayenne API and we want users to say
> "that Cayenne is so clear and easy to use". After all, ORM is often
> one of the most complicated libraries an average developer is likely
> to use.
>
> I understand the desire to keep backward compatibility and a simple
> migration path, but if a change needs to be made it should be the
> best possible and not the smallest possible.
I agree with the general sentiment, but I don't agree that it applies
to what I am suggesting.
'performQuery' in Cayenne has been around for 6 years (its analog
'objectsWithFetchSpecification' from EOF world - for much longer). I
don't see how anything we discussed here makes it obsolete or
embarrassing. We are simply porting this API to Java 5. And my
prediction is that it will be as usable in 5 years as it is now.
Here is how I see the main design abstractions of context and query:
* "query" is a _descriptor_ of an arbitrary database operation, with
no knowledge of the runtime (EOF explicitly calls it
EOFetchSpecification, "specification" == "descriptor"). While we
compromised on that in the backend by introducing query callback
methods ('createSQLAction', 'route'), those methods are extension
points that are not visible to the user.
* "context" is the environment facade object that executes queries.
I don't see how we will benefit by turning this around?
Andrus
This archive was generated by hypermail 2.0.0 : Thu Dec 27 2007 - 05:19:32 EST