I have a generic paging/sorting solution built on top of IQueryable. I had
the (unreasonable?) expectation that I would be able to retain that when
migrating to a newer and better version of NH.
I never said "NH should work-around everything".
I said (in slightly different words) "I'm willing to help NH work in the
best possible way with as many DBs as possible, while retaining
compatibility with previous versions".
And of course that also means scratching my own itch and helping others
while I do it.
If you think that this is NOT the NH and OSS philosophy... well, I'm
surprised.
Diego
On Wed, Jul 28, 2010 at 01:09, Fabio Maulo <[email protected]> wrote:
> 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
>
>
