For the pressure of your client let me know who is the doctor who said you that you must use LINQ in NH3 where you have: Criteria, HQL, QueryOver, H-SQL, SQL and obviously new embedded LINQ and even the "old" LINQ provider based on Criteria
I can do a little effort to understand you pressure if the new embedded-LINQ is the only way to query in NH.... but "IBM is not going to fix anything" does not mean "NH should work-around everything" On Tue, Jul 27, 2010 at 8:38 PM, Diego Mijelshon <[email protected]>wrote: > Yet, somehow, the old provider did it correctly. > Of course the limitation was that it _only_ supported a string as a > parameter and not a projection. > > Interestingly, the new provider does NOT translate > StartsWith(myPrefix + "m") > to > like @prefix || 'm' || '%' > It translates it to > like @prefix || '%' > where @prefix is the result of > myPrefix + "m" > > It only does that IF there are other projections. > > To wrap up: > - Steve did an AMAZING job with the new Linq provider. It supports like 10 > times more construct than the old one > - Any patch that we write for this should support BOTH the cases handled by > the new provider and the old one > - Keeping backward compatibility should be high in the priority list, and > that's one of the reasons to do CI, unless I'm mistaken > - Regarding Informix in particular, I can assure you that NO developer uses > it with NHibernate for pleasure :-) > - I respectfully disagree with the decision to close the ticket just > because you don't find it relevant (and we both know IBM is not going to fix > anything, and if even if they did, it's unlikely that my client will upgrade > to the latest version). I'm tring to provide the patch (I believe in the > giving and receiving nature of OSS, I'm not asking anyone to implement a > feature "because I want it"), but it's going to take a while. as I'm not > very familiar with the code. Steve, if you are reading and want to give me a > hand, it will be appreciated. > > Diego > > > > On Tue, Jul 27, 2010 at 19:10, Fabio Maulo <[email protected]> wrote: > >> That is not the solution because in OO what you have to write is: >> "something".Should().StartsWith("some"); >> >> but when you have to translate it for RDBMS you have to fit the mismatch >> translating it to a >> like 'some%' >> >> and ... >> var myPrefix = "so"; >> "something".Should().StartsWith(myPrefix + "m"); >> >> should be translated to >> like @prefix || 'm' || '%' >> >> >> 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 >> >> > -- Fabio Maulo
