cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Passing null values in parameters, part 2 )
Date Mon, 05 Oct 2009 08:07:52 GMT
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  


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.

View raw message