> Trying to understand whether the second option is redundant. Do you feel
> like option #1 won't be sufficient and we need to mix BindDirective with
> #bind? Maybe you have a good example why this is important?
Ok. Example... So now there is all queries with #bind($..) where
parameters are passed.. I tolled everyone to use bind everywhere...
it's not confusing to anyone who writes or fixes(modifies) queries.
So now we have type problem in query from first letter in this chain :
SELECT isnull(#bind($MyNumericColumn), AnotherNumericColumn) AS
MyColumn FROM MyTable
My wish is sometimes overwrite type mapping while passing parameters
especially null parameters via API (that is exactly my second option
wich is not redundant).
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...).
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.
Hope I wrote my thoughts in understandable way... :)
> BTW if we can come up with a sensible implementation of CAY-1282 that you
> just opened, it will be great. This will require some smart matching of
> column names obtained from ResultSetMetadata with explicitly mapped columns.
> Not impossible I guess.
Already post a patch for CAY-1282 ;) + JUnit. Looks like it's fixing things.
Also about #result directive... I wish to have ResultDirective also
for 2 cases: 1) to explicitly set type. 2) to overwrite type sittings
from #result (back compatibility for old queries is useful thing ).
P.S. Patch was for CAY-1282 ready in the morning (hours ago) but... I
couldn't login to Apache JIRA :((((
Did you had same problem or I should kick some Sys-admin to
reconfigure our proxy at work?...
Evgeny Ryabitskiy.
This archive was generated by hypermail 2.0.0 : Wed Sep 30 2009 - 11:21:25 EDT