> That is not the solution because in OO what you have to write is:
> "something".Should().StartsWith("some");
Why? .StartsWith() is a bool returning method usable in a predicate.
I have no idea why I should add '.Should()':
var q = from c in session.Linq<Customer>()
where c.CompanyName.StartsWith("Foo")
select c;
this is a simple, legitimate query which should result in a simple
select on customer with a LIKE predicate having the pattern "Foo%".
> but when you have to translate it for RDBMS you have to fit the mismatch
> translating it to a like 'some%'
that's not a mismatch, it exactly matches the rows you ordered it to
match.
> and ...
> var myPrefix = "so";
> "something".Should().StartsWith(myPrefix + "m");
>
> should be translated to
> like @prefix || 'm' || '%'
why should that translate to that?
myPrefix is an in-memory constant and "m" is a constant. This is
'funcletized' away (at least it _should_ by the linq provider) into a lambda
which is compiled into a delegate (that's 1 call) and ran in-memory at the
spot, resulting in "som". That's the constant then used in StartsWith().
If you don't scan for in-memory constructs and compile them into
delegates, you can't handle things like:
var q = from c in session.Linq<Customer>()
where c.CompanyName.StartsWith(GetCompanyStartFragment())
select c;
exactly the same thing.
Now, why does the o/r mapper core NEED to have the '%' been split
from the actual pattern?
FB
>
>
> On Tue, Jul 27, 2010 at 6:32 PM, Frans Bouma <[email protected]> wrote:
>
>
> > I have closed the issue.
> >
> > For me it is an external issue; we can't endorse all
workarounds...
> if an
> > RDBMS has an issue is not our problem and for some reason we give
> six ways
> > to query the persistence (4 are completely OO).
> >
> > I would like heard your opinions.
>
>
> I fail to see why the linq provider creates the second query
> (@p0+'%').
>
> The reason is that the StartsWith / EndsWith/Contains calls
on
> 'string' are easy to deal with and you can just formulate a like
> query with
> a pattern, no need for parameter concatenation (i.e.: the parameter
> value IS
> the pattern).
>
> I.o.w. a useless restriction (and IMHO a legitimate
> bugreport).
>
> FB
>
>
>
>
>
>
> --
> Fabio Maulo
>
