[
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
