[
https://issues.apache.org/jira/browse/DERBY-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151214#comment-13151214
]
Dag H. Wanvik commented on DERBY-5459:
--------------------------------------
Thinking more about this, I don't believe we should force a reprepare when (on
the client) we do ps.getMetaData: since it may be become stale at any time
between after the prepare and the execute, I think it is sufficient to re-send
the metadata with the execute (current patch): it can't be fully trusted to
predict the actual query results in the general case. Technically, this is in
break of the Javadoc wording:
"Retrieves a ResultSetMetaData object that contains information about the
columns of the ResultSet object that will be returned when this
PreparedStatement object is executed."
If this were to always hold, we'd need to lock all involved tables from DDL
operations till all prepared statements are closed. I don't think we want to go
there. Or? :)
> 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,
> 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
