> > Good point you brought up here. I can imagine escaping is the reason
> > why the '%' is separated (I asked a question about this, but it's not
> > answered) along the way, so you can do simple escaping without running
> > the risk of escaping the '%' character as well. The problem is though
> > that the '%' is separated in the _query_, which is odd, as I assume
> > the specific AST part, namely the LIKE expression part, is handled by
> > a method which only emits like fragments, and thus knows how to append
> > the '%' after it produces the escape line.
>
> Too many assumptions for me to follow up on, someone from the NH team
would
> have to weigh in here (if they want).
> For me, it would be much easier to follow this if I could see the interim
> HQL. As things are now, I often cannot tell whether something is rooted in
> LINQ to HQL or in HQL to SQL.
I think it depends how Linq to NH is converted to the AST and what
the AST is. If the AST is already in SQL ready format, it's essential to
solve these problems twice, in HQL and in Linq, which is IMHO a bit odd, but
it then requires an AST which is more richer of nature but harder to convert
to SQL.
> I just asked Steve, he said he could do it quite easily (but didn't say if
> he actually will ;-))
>
> >
> > Not all databases support the same escaping btw (or at all), so this
> > might be a dialect specific feature.
>
> I believe LIKE '100\%%' ESCAPE '\' to be ANSI SQL. Differences exist of
> course, such as the regex-like [...] in TSQL.
>
> http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
>
> 8.5 <like predicate>
>
> Function
>
> Specify a pattern-match comparison.
>
> Format
>
> <like predicate> ::=
> <match value> [ NOT ] LIKE <pattern>
> [ ESCAPE <escape character> ]
Sadly what's in the standard isn't in the databases out there. For
example T-SQL supports more wildcards than DB2 or Oracle for example, so
escaping [] is not useful on oracle (as you don't need to).
FB
