[
https://issues.apache.org/jira/browse/DERBY-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127290#comment-13127290
]
Dag H. Wanvik commented on DERBY-5459:
--------------------------------------
>From looking at the code in client PreparedStatement#getMetaData, which calls
>getMetadataX, there is no attempt to verify that the prepared statement's
>metadata is still up-to-date. Repreparing the ps does bring it up to date,
>though. Perhaps we should just disabled this caching and reprepare whenever
>PreparedStatement#getMetaData is called. On the server this will not
>necessarily lead to a recompilation, of course. It does, however, incur a
>client server round-trip, but since we don't have any push service, I think
>polling is the only way to get the correct behavior.
But it doesn't stop there: if we (re)execute the prepared statement (for which
the cached metadata on the client is out of date), a new result set resulting
from a query using that ps will inherit the stale metadata from the ps, cf.
Statement#completeOpenQuery ca line 1493:
resultSet.resultSetMetaData_ = resultSetMetaData_;
so the metadata for the newly retrieved result set will also be stale (since
the execution doesn't presently signal that the metadata has changed in any
way). Thinking aloud, maybe we could version the metadata and attach the
version number to the query result. If the cached version were out of date the
client would need to retrieve the result set's metadata before closing the
result set (so it would be guaranteed to be correct: the server does keep the
info as long as the rs is open I think).
> 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, 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
