db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5459) Result set metadata are out of sync on client after underlying table is altered
Date Thu, 17 Nov 2011 16:00:53 GMT

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

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

Regressions passed. I'll await a review before I commit this this change. Experienced DRDA
folks might want to check if what I am doing here violates the protocol: although the client
code accepts the SQLDARD block in parseOpenQuery, that could be "accidental" (intended for
other cases). I tried to grok the standard on this point; it seemed to me that for this block
to be returned, the app should *ask* for it. However, I have not changed to client code to
do this. Obviously, it's nice not to have the change the client code for compatibility reasons.
And this the block is sent as a result of a server event, it would be impossible to have the
client ask for it, unless we choose to always return it.
                
> 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

        

Mime
View raw message