> "your framework" ?
> I don't know what you mean.
well, NH is 'owned' by the people who can change it, i.e. the people
who are allowed to make changes, thus the team. Like the group who decided
to close 2254 and the group who can't answer simple questions on the
official mailing list about why the '%' is appended in an expression instead
of inside the parameter value itself.
> I was talking about a Team and not a person and, btw, in my world any OSS
> project is owned by the cloud.
usage rights maybe, but if 'the cloud' owned the OSS project this
discussion wouldn't be necessary. However, it IS necessary because someone
(you) decided to close a bug. While that's perhaps totally right, you
decided it was perhaps necessary to ask for a discussion here. What's
amusing to see is that the people who actively participate in technical
discussions about the matter are not people who contribute, i.e. 'the team'.
The team itself is silent.
Writing a linq provider takes a lot of dedication and focus, you
can't just 'jump in and provide a patch', that's not going anywhere. You
have to design the thing from start to finish, write tools to help you
develop the thing (like visualizers which view the various stages of the
expression tree), and implement the various stages. You however seem to
think it's a matter of 'someone will come up with a patch for <feature> /
<bug>'. No way in hell that that's going to work for the linq provider.
I thought you were the project lead of NHibernate? If you are, stop
bickering here and start forming a team with dedicated people who know wtf
it is all about to write a linq provider. I am here on this list to see if I
can help, but my experiences so far are below expectations: as if you don't
need my help. But, Fabio, I already solved the problems of your linq
provider 3 years ago. If you don't want my help or the help of other
seasoned linq provider writers, fine by me, but don't think it will
eventually come along fine, it won't.
Unless Steve S. manages to spend more time on the project, but the
poor guy is already swamped with work, it seems.
> See you to the next coming soon feature.
> http://216.121.112.228/browse/NH-2256
Ah yes, sounds very familiar, with one exception: here, the mistake
is made to use 1 registry.
You need 1 per dialect. In there you register .NET methods, per
type, per # of parameters and store a fragment (or whatever you use to
convert to SQL) which is able to convert the function to SQL for that
dialect/db. Per dialect you pre-define a list of DB functions, like CAST,
CONVERT, ABS, CASE and what not.
Then the same mechanism / class can be used by NH users to define
their OWN .net method to SQL fragment mapping. The user then creates such a
class, and passes it to the session when a linq query is formulated. This
user provided registry overrides the one in the dialect which is active in
the session, if a method is mapped twice.
In the MethodCall expression handler early on you look up the
fragment to convert the function to and convert it to your own expression
with the fragment.
That's it. Works very simple and flexible. Usage example:
http://www.llblgen.com/documentation/3.0/LLBLGen%20Pro%20RTF/hh_goto.htm#Usi
ng%20the generated code/Linq/gencode_linq_functionmappings.htm
Maps everything in all situations.
I won't provide a patch for you at this moment, as I have no
knowledge of the nh linq provider internals, and that will take a lot of
time to get into, but maybe someone on the 'team' could use this to get
things forward.
FB
>
> On Wed, Jul 28, 2010 at 1:23 PM, Frans Bouma <[email protected]> wrote:
>
>
> > Step by step you will see how we will give the ability to extend
> our Linq-
> > Provider giving you the way to inject the translation of your own
> LINQ-
> > extension-methods.
> > Doing so, you can implement a string extension named Like, working
> in RAM,
> > and can be translated to SQL.
> >
> > Hopefully, in this way, all users can find his own way to
translate
> > StartsWith, EndsWith, Length, Count(), Count, and so on and
perhaps
> somebody
> > will share his solution in the same way they share his opinion.
>
>
> If you want a solution for that, just ask. (and whether when
> it's a
> good idea or not). However till now, what I've read here we just
have
> to
> wait and not say anything. Fine by me, but you and your framework
> aren't
> helped by that IMHO.
>
> FB
>
>
> >
> >
> > On Wed, Jul 28, 2010 at 12:41 PM, Wenig, Stefan
> <[email protected]>
> > wrote:
> >
> >
> > > -----Original Message-----
> > > From: [email protected]
> [mailto:nhibernate-
> > > [email protected]] On Behalf Of Frans Bouma
> > >
> >
> > > 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 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> ]
> >
> >
> >
> >
> >
> > --
> > Fabio Maulo
> >
>
>
>
>
>
>
>
> --
> Fabio Maulo
>
