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