Patch for jdbc escaped functions

Hi,
I saw that escaped functions were on the TODO list.
Here is a patch that prepare for adding escaped functions.
It supports nested escapes.
As example I have coded the concat function.
Tests and metadata updates are included.
If the patch is accepted, I will add more functions.
Any comments are welcome.

On Fri, 19 Nov 2004, Xavier Poinsard wrote:

> Hi,
> I saw that escaped functions were on the TODO list.
> Here is a patch that prepare for adding escaped functions.
> It supports nested escapes.
> As example I have coded the concat function.
> Tests and metadata updates are included.
> If the patch is accepted, I will add more functions.
> Any comments are welcome.
>

This code is not quite right in its determination of function arguments
because it stops checking for literal and identifier markers.
Consider that {fn concat('(', a."(")} should work.

I also don't like the prospect of a giant if/else block that has every
function that must do some kind of mapping/translation. What about a more
pluggable architecture perhaps along the lines of the following:

public interface StandardFunction {
public void toSQL(StringBuffer sb, ArrayList args);
}

Then a static HashMap of say lowercase function name -> StandardFunction
implementation can move all of the mapping/translation into a separate
place. Maybe that's overkill in the opposite direction. Thoughts?

Kris Jurka

Kris Jurka wrote:
> This code is not quite right in its determination of function arguments
> because it stops checking for literal and identifier markers.
> Consider that {fn concat('(', a."(")} should work.

Thanks for pointing these defects.
I added this to the parsing and your example to the tests.

>
> I also don't like the prospect of a giant if/else block that has every
> function that must do some kind of mapping/translation. What about a more
> pluggable architecture perhaps along the lines of the following:
>
> public interface StandardFunction {
> public void toSQL(StringBuffer sb, ArrayList args);
> }
>
> Then a static HashMap of say lowercase function name -> StandardFunction
> implementation can move all of the mapping/translation into a separate
> place. Maybe that's overkill in the opposite direction. Thoughts?

I used reflection to move the translation part to EscapedFunctions class.
Right ?

On Mon, 22 Nov 2004, Xavier Poinsard wrote:

> > I also don't like the prospect of a giant if/else block that has every
> > function that must do some kind of mapping/translation. What about a more
> > pluggable architecture perhaps along the lines of the following:
> >
> > public interface StandardFunction {
> > public void toSQL(StringBuffer sb, ArrayList args);
> > }
> >
> > Then a static HashMap of say lowercase function name -> StandardFunction
> > implementation can move all of the mapping/translation into a separate
> > place. Maybe that's overkill in the opposite direction. Thoughts?
>
> I used reflection to move the translation part to EscapedFunctions class.
> Right ?
>

I'm not sure why you are using reflection. The available functions will
be a static list, so I don't see what the purpose of dynamically
inspecting this class is. Having one class instead of dozens?

Kris Jurka

Kris Jurka wrote:
>
> On Mon, 22 Nov 2004, Xavier Poinsard wrote:
>
>
>>>I also don't like the prospect of a giant if/else block that has every
>>>function that must do some kind of mapping/translation. What about a more
>>>pluggable architecture perhaps along the lines of the following:
>>>
>>>public interface StandardFunction {
>>> public void toSQL(StringBuffer sb, ArrayList args);
>>>}
>>>
>>>Then a static HashMap of say lowercase function name -> StandardFunction
>>>implementation can move all of the mapping/translation into a separate
>>>place. Maybe that's overkill in the opposite direction. Thoughts?
>>
>>I used reflection to move the translation part to EscapedFunctions class.
>>Right ?
>>
>
>
> I'm not sure why you are using reflection. The available functions will
> be a static list, so I don't see what the purpose of dynamically
> inspecting this class is. Having one class instead of dozens?

Yes, considering the fact that each implementation would only consist of
five lines of codes, it seems overkill to have one class per function.
To avoid inspecting at every call, I could use a static HashMap
containing references to Method objects.

>
> Kris Jurka