Re: Passing null values in parameters, part 2 )

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Oct 05 2009 - 04:07:52 EDT

  • Next message: Andrus Adamchik: "Beta 1 ?"

    Hi Evgeny,

    Thanks for explaining it in detail. I think now I am clear on the
    proposed scope of the feature and the motivation behind it. While this
    didn't change my initial assessment of the redundancy of the
    #bind($bind) option, still I see no harm in the extra functionality of
    the #bind directive, especially considering that you will be
    submitting a patch for it (so I agree to disagree :-)). So let's go
    for it.

    I suggest that we don't limit it to just #bind($bind), but support it
    for all flavors of the bind directive. Also like CAY-1282, this is
    something that will go to 3.0 only. As we've contemplated doing a 3.0
    beta release soon, keep us posted on the progress, as beta would also
    mean a complete feature freeze for 3.0. And on the upside, it may mean
    that your company can start using 3.0 as an API-stable release in your
    work.

    Thanks,
    Andrus

    On Oct 4, 2009, at 6:56 PM, Evgeny Ryabitskiy wrote:

    >> So this argument is based on the fact that people are using #bind()
    >> already.
    >> With the new approach they'd just need to optionally change the Java
    >> parameter code, and the alternative would be to change both
    >> template code as
    >> well as Java code.
    >
    > Yes! My argument is based on that people are using #bind already in
    > our NamedQueries in our xml files... And no one want to change
    > something that was written once and still working...
    > Maybe one thing that I forgot to tell... Any our NamedQuery can be
    > used in lot's of places... Yeah... huge bank systems....
    > And I can't change it one place from Java and one from queries. I
    > should find every use of this query in Java and change it to use
    > BindObject.... it's too painful!
    > So that is why Queries should be independent from Java-code, that is
    > why I need queries in one stile and can't just delete somewhere #bind
    > and somewhere not.
    > So again I have only 2 options.. no compromises: 1)everywhere #bind;
    > 2) nowhere #bind and special BindObject everywhere in Java Code.
    >
    > I am not going to choose second option... :) So without overwriting
    > this API tool is useless for us.
    > I know Cayenne is not just for me and my project (even my project is
    > great!)... but I also don't think that my case is so unic.
    > I'm not along who wish to have queries in one style!
    >
    >
    >> I am still not convinced that the second option is any
    >> harder or more confusing. To me the first option is confusing
    >> actually -
    >> when I pass a binding object, and the directive already has some
    >> properties,
    >> it is not immediately obvious which set of properties will take
    >> effect.
    >
    > For me and my team it's absolutely not confusing. Look.. we have some
    > NamedQuery.. it's used in several places.
    > So in one place we are passing null and I wish to pass type with this
    > null to do some hint for JDBC driver to use right type mapping.
    > So I am overwriting default mapping from #bind($..) by BindValue
    > object and... few lines later.. I am expecting right type mapping in
    > result. Don't think it should be confusing to developer.
    >
    >> Just like you in this case, I always look at the new API from the
    >> point of
    >> view of whether it is internally consistent and easy to explain to
    >> the end
    >> users. In this case I think having "$xyzSpecialObject" as an
    >> alternative to
    >> an "#XYZ" directive seems like a straightforward symmetrical
    >> replacement. At
    >> the same time using "#XYZ($xyzSpecialObject $p1 $p2 $p3)" as a way to
    >> override some parameters appears indeterministic to an uninitiated
    >> person.
    >
    > When I was talking about overwriting I had in mind just #bind($...)
    > directive, without explicit set of JDBC type.
    > The point of "my" overwriting is to control implicit binding (where is
    > no JDBC type parameter in SQLTemplate).
    > So maybe in case of #bind($param 'VARCHAR') it can be confusing to
    > overwrite type from API.
    >
    > So... I can suggest one more compromise to overwrite #bind($..) only
    > where is no explicit JDBC type. Less confusing... more safe from
    > developer point....
    >
    >
    > Evgeny Ryabitskiy.
    >



    This archive was generated by hypermail 2.0.0 : Mon Oct 05 2009 - 04:09:23 EDT