The dialect as the ILinqToHqlGeneratorsRegistry are per sessionFactory as the configuration is per-sessionFactory.... Well... I'm going to implements it... it will be faster than explain you how it will work (only because I can write a better C# than a good English).
On Wed, Jul 28, 2010 at 4:21 PM, Frans Bouma <[email protected]> wrote: > > "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 > > > > > -- Fabio Maulo
