From derby-dev-return-97064-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Wed Jul 18 01:41:52 2012 Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 148C3D206 for ; Wed, 18 Jul 2012 01:41:52 +0000 (UTC) Received: (qmail 56142 invoked by uid 500); 18 Jul 2012 01:41:51 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 56100 invoked by uid 500); 18 Jul 2012 01:41:51 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 56093 invoked by uid 99); 18 Jul 2012 01:41:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jul 2012 01:41:51 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [98.138.91.37] (HELO nm18-vm0.bullet.mail.ne1.yahoo.com) (98.138.91.37) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 18 Jul 2012 01:29:08 +0000 Received: from [98.138.90.49] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jul 2012 01:28:46 -0000 Received: from [209.191.108.96] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jul 2012 01:28:46 -0000 Received: from [66.94.237.110] by t3.bullet.mud.yahoo.com with NNFMP; 18 Jul 2012 01:28:45 -0000 Received: from [127.0.0.1] by omp1015.access.mail.mud.yahoo.com with NNFMP; 18 Jul 2012 01:28:45 -0000 X-Yahoo-Newman-Id: 975410.10182.bm@omp1015.access.mail.mud.yahoo.com Received: (qmail 23464 invoked from network); 18 Jul 2012 01:28:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=pSQRg0AP1Io0l7yDFV8Gpw5J+lpPsFbdmrl2wTJopVw0N80yVaDwouh+cA7a1tPyuGdGtF9nSg/BZC0ZM535ZK5LQmjh/0CQkJTsKgOUVT/6OdiJU98ty/NvVf7usfpac8sfuaQAJH8LAGsckFAZ+ssnON4qn4ohRK+5kfB4aNk= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1342574925; bh=nIMep3eOOwxAgxlLh6RMmntqymJYLHoKrHYjrJU39bs=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=hx64ritZYsT9qM1+vJlfEeibyP95XSYogJqI9wdMzS7vB54xY9uOMChoEtsbCJdXQGyCi+iHE6R2h6RJrhus2wXGWDcH/4kdVnbJ3phWi8XSgtjaiCw3xwQ6Qg+s6M9sdH4o8ZCY+8/6VdP7QyhVawNv8yS6Fvp6lb4sulGILX8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qB5GFxsVM1nCKYGxHwawbGctZDDAFEDU7Vr6QeDqa4BoYM_ kD4.VqxDxvk7B_lZBMYtR75UzQf61GZFo_oOBx1keYHf7MEv2EagHeFuWiHN 3PVkO1PcO5PGZHByDA9.VYCkUfFLptI4NL6vtsRYZDf0FBq8UQNfEI_wakkC NWnY3_9m008E4pv0JlXt2RZsbLanvfHYTM6raGE51gY7WUyh5wAdagGdZ2Hu pnOsJfLwaeNzQ_X2UeKGdhIFJB_.qNDI_aij5wbhEm8h_69JWWdzOJEvrU06 r2DluVBrv6lPEwGcghpcIM0LdMsaOucDzZ7mIgMuBfb0F0L6U2FKqYuUYSeA agjR5T_8YrrtveJLiCZ28yJu1Omvr6kmMU1B6Hit5fFTOKJgNxRCTuplr_Dw I345ohkaEQ2Bu1iYnaFQCZ2NorDiYLIVobb__2IMt6qIr9mXIxVJS4NB7sB0 4Xe04GbqTduOO0vKUlh6d22Kor6HcfKcMfwkVX4VdE3qzec2FNV8.oqBebJP FTmv.9jW66gDcQul0xF8yF0yIH.rvdbGL7xCdmHcikBN8hv98NJq1Jz.O_E1 2 X-Yahoo-SMTP: fBd8VESswBBwVkX.d9lIdXduzED_6kJxUAzIjM21tL._95FbORG0yg-- Received: from [192.168.1.71] (kmarsdenderby@108.231.78.45 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 17 Jul 2012 18:28:45 -0700 PDT Message-ID: <5006113B.7010306@sbcglobal.net> Date: Tue, 17 Jul 2012 18:28:27 -0700 From: Katherine Marsden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Re: derby getProcedureColumns References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040309050805050106090909" This is a multi-part message in MIME format. --------------040309050805050106090909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/17/2012 8:54 AM, LUTTER, Steffen wrote: > > Hello, > > I have an issue with stored procedures in derby and like to ask for > your confirmation. When querying the procedure columns, according to > the JDBC standard we escape pattern characters, like _ and % if > necessary. The escape character is here taken from the function > getSearchStringEscape(). > Derby returns an empty string for getSearchStringEscape() and the comments indicate we don't have a default escape value. I am not sure why. I am also not understanding where = comes in the picture according to the comment below: /** * This is the string that can be used to escape '_' or '%' in * the string pattern style catalog search parameters. we have no default escape value, so = is the end of the next line *

The '_' character represents any single character. *

The '%' character represents any sequence of zero or * more characters. * @return the string used to escape wildcard characters */ public String getSearchStringEscape() { return ""; } I think it would be worthwhile to file a Jira for Derby to allow escape of the wildcard characters in the pattern unless someone understands why we don't support it. > The problem is, that derby doesn't seem to accept the escaping in case > of _ (underscore), and uses the escape characters within the match > which leads to the situation that the stored proc is not found. > > Example: > > We have a stored procedure MY_PROC. > > getConnection ().getMetaData ().getProcedureColumns (null, null, > "MY\\_PROC" ,"%") => *Stored proc is not found* > > getConnection ().getMetaData ().getProcedureColumns (null, null, > "MY_PROC" ,"%") => *Stored proc is found* > > The first case is the problem, as the _ needs escaping. For the second > case it works, even though theoretically also procedures called > MY-PROC, MY+PROC, MYXPROC would match. > > Have I overseen something? Can you confirm? > > http://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html > > Many thanks in advance, > > Steffen > > _________________________________________________________________ > > *Steffen Lutter*| Developer | Semantic Layer | TIP BAT EIM | +33 1 41 > 25 38 68 > --------------040309050805050106090909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 7/17/2012 8:54 AM, LUTTER, Steffen wrote:

Hello,

 

I have an issue with stored procedures in derby and like to ask for your confirmation. When querying the procedure columns, according to the JDBC standard we escape pattern characters, like _ and % if necessary. The escape character is here taken from the function getSearchStringEscape().

Derby returns an empty string for getSearchStringEscape() and the comments indicate we don't have a default escape value.  I am not sure why. I am also not understanding where = comes in the picture according to the comment below:

/**
     * This is the string that can be used to escape '_' or '%' in
     * the string pattern style catalog search parameters.
        we have no default escape value, so = is the end of the next line
     * <P>The '_' character represents any single character.
     * <P>The '%' character represents any sequence of zero or
     * more characters.
     * @return the string used to escape wildcard characters
     */
    public String getSearchStringEscape()  {
        return "";
    }

I think it would be worthwhile to file a Jira for Derby to allow escape of the wildcard characters in the pattern unless someone understands why we don't support it.

The problem is, that derby doesn’t seem to accept the escaping in case of _ (underscore), and uses the escape characters within the match which leads to the situation that the stored proc is not found.

 

Example:

 

We have a stored procedure MY_PROC.

 

getConnection ().getMetaData ().getProcedureColumns (null, null, ”MY\\_PROC” ,"%") => Stored proc is not found

 

getConnection ().getMetaData ().getProcedureColumns (null, null, ”MY_PROC” ,"%") => Stored proc is found

 

 

The first case is the problem, as the _ needs escaping. For the second case it works, even though theoretically also procedures called MY-PROC, MY+PROC, MYXPROC would match.

 

Have I overseen something? Can you confirm?

 

http://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html

 

Many thanks in advance,

 

Steffen

 

_________________________________________________________________

Steffen Lutter | Developer | Semantic Layer | TIP BAT EIM | +33 1 41 25 38 68

 



--------------040309050805050106090909--