[
https://issues.apache.org/jira/browse/DERBY-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5459:
---------------------------------
Attachment: derby-5459-1.stat
derby-5459-1.diff
Uploading a trial patch, derby-5459-1, which fixes the problem in the following
way: Each time we (recompile) a statement, a counter is incremented. When we
first explicitly prepare a statement from the client, we make a note in
DRDAStatement to which version of the compiled statement the prepare
corresponds. Later, when executing the statement, if it returns data, we
compare the current version of the prepared statement with the one current when
the stament was compiled. If the versions differ we can be sure the client has
stale metadata for the prepared statement, and we attach a SQLDARD block to the
retiurned data. This is picked up by the client ok, it seems, cf the code in
NetStatementReply#parseOpenQuery:
if (peekCP == CodePoint.SQLDARD)
The patch also updates the test PrepStmtMetaDataTest to assert metadata for
the result set after an ALTER statement.
Note, DERBY-2402 also notes that before executing a query after the ALTER, the
client's ps metadata is out of synch. The patch does not address this problem:
it is fairly easy make the client's getMetaData method always do a reprepare
but this may not be what we want.
Comments welcome on the approach as well as on the implementation.
Running regressions.
> 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
> Attachments: Repro.java, derby-5459-1.diff, derby-5459-1.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
