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
