Re: Passing null values in parameters, part 2 )

[Andrus Adamchik <an...@objectstyle.org>]

On Sep 30, 2009, at 6:21 PM, Evgeny Ryabitskiy wrote:
> Without this option I have to variants:
> 1) Change #bind($....) to $... everywhere and every time pass our
> special mapping objects to parameters (I will die/be killed by
> colleges early...).

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. 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.

> 2) Use not general style in SQLTemplate, somewhere with #bind,
> somewhere not... Firstly it's confusing... Second Is potential errors
> when I forget where I should pass simple Object and where is special
> bind object.

Our current approach with Velocity templates is by definition error- 
prone, as there's no parameter type checking anywhere. IMO adding the  
new option won't make it better or worse in this respect.

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.

Cheers,
Andrus

Re: Passing null values in parameters, part 2 )

[Andrus Adamchik <an...@objectstyle.org>]

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.
>

Re: Passing null values in parameters, part 2 )

[Evgeny Ryabitskiy <ev...@gmail.com>]

> 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.