String index
3 views
Skip to first unread message
Pascal Craponne
Sep 15, 2008, 5:46:50 PM9/15/08
to DbLinq
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
2. If the above value it true, then we set the involved argument Expression.Add(originalExpression,Expression.Constant(1)) when creating the SpecialExpression.
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.
Matthew Snyder
Sep 15, 2008, 6:03:53 PM9/15/08
to DbLinq
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?
-
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?
-
Pascal Craponne
Sep 15, 2008, 6:24:27 PM9/15/08
to dbl...@googlegroups.com
yes, you just need to apply the same pattern to all string manipulation methods :)
Pablo Iñigo Blasco
Sep 15, 2008, 7:05:57 PM9/15/08
to dbl...@googlegroups.com
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.
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 <pic...@gmail.com> wrote:
> 2. If the above value it true, then we set the involved argument
> Expression.Add(
originalExpression,Expression.Constant(1)) when creating the
> SpecialExpression.
> 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 <Matthew....@gmail.com> 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" <pic...@gmail.com> 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.
>
--
Saludos. Pablo Iñigo Blasco .
Pascal Craponne
Sep 16, 2008, 3:19:19 AM9/16/08
to dbl...@googlegroups.com
We found the guilty one. Let's burn him :)
Reply all
Reply to author
Forward
0 new messages