Re: performQuery generics

From: Aristedes Maniatis (ar..sh.com.au)
Date: Thu Dec 27 2007 - 03:52:59 EST

  • Next message: Andrus Adamchik: "Re: performQuery generics"

    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



    This archive was generated by hypermail 2.0.0 : Thu Dec 27 2007 - 03:53:42 EST