On 26/12/2007, at 9:49 PM, Andrus Adamchik 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.
Since Query interface is another core Cayenne abstraction, adding
utility methods to it is causing a similar ripple effect as adding
them to ObjectContext... E.g. a DeleteBatchQuery would now have a
'getResult' method... Also we'd have to add update methods returning
update counts, select methods returning Object[] (something we are
implementing now per JPA), etc... In other words, too many loose ends.
Wouldn't they be added just to SelectQuery and not to the interface?
The query interface seems to represent something much more abstract -
the idea of an interaction with the database.
Again, because I don't have the skills or knowledge (not to mention
time) to make the required changes within the heart of the query
classes I feel like a hack making all these suggestions - but I hope
they are useful ideas.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
