> 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 : Sun Oct 04 2009 - 11:57:44 EDT