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.
