db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (DERBY-5459) Result set metadata are out of sync on client after underlying table is altered
Date Tue, 15 Nov 2011 14:35:51 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150519#comment-13150519
] 

Dag H. Wanvik edited comment on DERBY-5459 at 11/15/11 2:33 PM:
----------------------------------------------------------------

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: particularily, should we
perhaps also do a reprepare when PS.getmetadata is called or is that too heavy handed..

Running regressions.
                
      was (Author: dagw):
    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

        

Mime
View raw message