On Wednesday, June 4, 2003, at 09:00 AM, Holger Hoffstätte wrote:
>>> The solution is:
>>> WHERE UPPER(name) LIKE UPPER(CAST(? AS VARCHAR (100)))
>
> I have now hit exactly this problem and Mario was right: the eror
> occurs
> with bind variables. In my mail I suggested a look at
> QualifierTranslator
> and TrimmingQualifierTranslator but this proved to be less helpful
> than I
> expected because (I think) the processColumn method in
> QualifierTranslator
> does 'too much' and cannot easily be overridden to provide the
> necessary
> CAST .. AS VARCHAR conversion.
Let's make sure I understand what causes this problem. Is it the lack
of "CAST(? AS VARCHAR (100))" in the query or the actual binding of a
value to PreparedStatement that already has this piece of SQL magic?
In any event, I need some more time to look into this...
> I tried to wedge
> willProcessColumn/didProcessColumn methods in there but it's still too
> early. The only way around this that I can see would be a full
> duplication, which would not be acceptable, IMHO.
> Andrus, do you see any other way around this that I've been missing?
> The
> entire QueryAssembler/Helper setup is somewhat confusing
Agreed. Qualifier translation process has a major problem of being
coded in Java instead of a generic parser language, like Java CC.
Originally I couldn't find an easy way to integrate it with
JavaCC...and now when the number of rules that it handles grew up
substantially, it is a nightmare to maintain. Too late to change
anything for this release, but in the future we will need to do
something about it (maybe in combination with parsable string
expressions).
Andrus
This archive was generated by hypermail 2.0.0 : Fri Jun 06 2003 - 02:05:13 EDT