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