Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 22 Nov 2011 09:48:40 +0000 (UTC)
From: "Knut Anders Hatlen (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <778063621.1897.1321955320351.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <604900336.7749.1318476191940.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5459) Result set metadata are out of sync
 on client after underlying table is altered
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154980#comment-13154980 ] 

Knut Anders Hatlen commented on DERBY-5459:
-------------------------------------------

I agree with Dag's reading of the DRDA spec. DRDA v4, vol 3 says that an OPNQRY command may return an SQLDARD object (see last paragraph on page 541). However, there are some variables in the OPNQRY command that controls whether or not to return it, so the opportunistic approach in the patch is probably not strictly adhering to the spec. Sounds like a reasonable extension, though, but it might warrant a code comment saying it is an extension (possibly also on the client side, so that no one accidentally removes the code that reads the SQLDARD object because the client code hasn't requested it).

Before checking in the changes, it might be useful to run the regression tests with a modified patch that sends an SQLDARD unconditionally, and see if that smokes out hidden problems.
                
> Result set metadata are out of sync on client after underlying table is altered
> -------------------------------------------------------------------------------
>
>                 Key: DERBY-5459
>                 URL: https://issues.apache.org/jira/browse/DERBY-5459
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: Repro.java, derby-5459-1.diff, derby-5459-1.stat, derby-5459-2.diff, derby-5459-2.stat, repro-patch.diff
>
>
> Cf the discussion on DERBY-3823.
> The enclosed repro program shows what happens. When I run it with
> client/server and embedded respectively we see these two differing
> results:
> client/server:
> $ java -cp .:$CLASSPATH Repo
> Done loading data
> executing alter
> execp.getResultDescription: select * from t1
> 2. PS#getMetaData: char column length is 8
> Reexecuting ps on changed table...
> 3. RS#getMetadata: char column length is 8
> data:1 12345678
> dag@T61pOS:~/java/sb/apps/derby3823$ !rm
> rm -rf DERBY3823DB
> embedded:
> dag@T61pOS:~/java/sb/apps/derby3823$ java -cp .:$CLASSPATH Repro 2
> execp.getResultDescription: insert into t1 values(?,'aaaaa')
> execp.getResultDescription: insert into t1 values(?,'aaaaa')
> Done loading data
> execp.getResultDescription: select * from t1
> execp.getResultDescription: select * from t1
> executing alter
> 2. PS#getMetaData: char column length is 5
> Reexecuting ps on changed tableh...
> 3. RS#getMetadata: char column length is 5
> data:1 12345678
> As we can see, the metadata results are different after the ALTER
> TABLE. The trace from EmbedPreparedData
> ("execp.getResultDescription:") lines (see repro-patch.diff) show that
> after ALTER, the metadata are not refreshed on the server side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira