[
https://issues.apache.org/jira/browse/DERBY-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155913#comment-13155913
]
Bryan Pendleton commented on DERBY-5459:
----------------------------------------
Hi Dag, thanks for working on this; it's been very interesting to follow along
on your analysis.
What is the (approximate, general) overhead of sending the result set metadata
to the client?
I guess I'm wondering if we should just *always* send that data. Such an
approach might be
simpler, and I'm always interested in raising the question of whether a simpler
implementation
might work adequately.
> 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
