We found the guilty one. Let's burn him :) On Tue, Sep 16, 2008 at 01:05, Pablo Iñigo Blasco <[EMAIL PROTECTED]> wrote:
> Hi guys! > > That's my blame. I made such implementation during the summer when I was > implementing string operations (substring, indexof, remove, replace, > trim..), all of them using the same convention (if you find a error in one > operation it probably will exist for the rest of operations). > > When I implemented such string operations they worked fine for postgre and > mssql, but now a lot of tests fail. :-S . Nonetheless I agree with you that > the SqlProvider implementation isn't the most beautiful one. > > I made such implementation in August, from 6th(r842) to 10th(r849). If you > want you cant take a quick look to those commit, if SqlProvider > implementation is wrong maybe (though I don't think so) other parts of such > implementation are also bad. It is all ways interesting another point of > view. > > On Tue, Sep 16, 2008 at 12:24 AM, Pascal Craponne <[EMAIL PROTECTED]>wrote: > > 2. If the above value it true, then we set the involved argument > > Expression.Add( > originalExpression,Expression.Constant(1)) when creating the > > SpecialExpression. > > If we are going to do this, probably we'll have to do some modifications in > Specialexpression.Execute method and ExpressionDispatcher.AnalyzeCall method > too (in addition to SqlProvider modifications). > > Regards. > > > yes, you just need to apply the same pattern to all string manipulation >> methods :) >> >> >> On Tue, Sep 16, 2008 at 00:03, Matthew Snyder <[EMAIL PROTECTED] >> > wrote: >> >>> >>> Pascal - >>> >>> You're absolutely right. I'll put that together the next time I'm >>> home. >>> >>> Does that mean the "1" constant in src/DbLinq/Vendor/Implementation/ >>> SqlProvider.cs (like line 466) will be refactored too? >>> >>> - >>> >>> On Sep 15, 5:46 pm, "Pascal Craponne" <[EMAIL PROTECTED]> wrote: >>> > Hi Matthew, >>> > the option you chosed to implement string index (in substrings, for >>> example) >>> > causes two problems: >>> > 1. it can not be optimized, since it comes at SQL generation level, >>> thus >>> > we'll get some "-1" (and I don't understand why it is not a "+1", but >>> that >>> > is not the point) >>> > 2. it works only for Oracle, and that's too selfish :) Some SQL >>> providers >>> > may have the same problem too. >>> > >>> > So here's my suggestion: >>> > 1. ISqlProvider gets a StringIndexStartsAtOne property >>> >>> > 3. When the special expression is translated again in CLR, the involved >>> > argument coming for SpecialExpression is reverted. >>> > Don't mind if it seems heavy, place such manipulations in a single >>> method. >>> > Such expressions will be optimized when possible (when a constant is >>> used), >>> > so we're all good. >>> > >>> > -- >>> > Pascal. >>> > >>> > jabber/gtalk: [EMAIL PROTECTED] >>> > msn: [EMAIL PROTECTED] >>> >>> >> >> >> -- >> Pascal. >> >> jabber/gtalk: [EMAIL PROTECTED] >> msn: [EMAIL PROTECTED] >> >> >> >> > > > -- > Saludos. Pablo Iñigo Blasco . > > > > -- Pascal. jabber/gtalk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
