Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Thu, 24 Nov 2011 23:36:40 +0000 (UTC)
From: "Dag H. Wanvik (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1245065085.10748.1322177800164.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=13156935#comment-13156935 ] 

Dag H. Wanvik commented on DERBY-5459:
--------------------------------------

With the patch to Emma, the fix to DERBY-5512 (thanks, Knut) and setting the path the the old releases when calling ant (since i'm behind a firewall), I was able to make all tests in ant target "derby-core" run with emma jars, albeit a few at a time. I'll start all the tests now passing larger heap size etc in via ANT_OPTS, so I'll see how far I get with Emma running the "emma-all" target. It would be nice to have it running again. 
                
> 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
>             Fix For: 10.9.0.0
>
>         Attachments: Repro.java, derby-5459-1.diff, derby-5459-1.stat, derby-5459-2.diff, derby-5459-2.stat, derby-5459-3.diff, derby-5459-3.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