[
https://issues.apache.org/jira/browse/DERBY-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641912#action_12641912
]
Kathey Marsden commented on DERBY-3919:
---------------------------------------
Well the build number is not considered as part of the version information
considered for clearing the SPS plans. A quick fix for this problem on 10.1
would be to bump the last digit to 10.1.3.3 and then the sps plans will get
cleared when the user upgrades.
As for a general long term solution I see the following options.
1) Always bump the last digit when generated code changes.
2) Bump the last digit with any change on a branch.
3) Somehow get the build number incorporated into the version number
information stored in the database so that we clear sps plans when the build
number changes.
I personally prefer option 2. I think it makes the version numbers clearer.
Often user reports have the version but not the build number and that would
help mitigate that problem as well.
I will go ahead and bump the last digit on 10.1, but would like input on a more
long term solution.
Thanks
Kathey
> Changing derby versions can cause java.lang.NoSuchMethodError on
> DatabaseMetaData call
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-3919
> URL: https://issues.apache.org/jira/browse/DERBY-3919
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
>
> Running the following program on 10.1 latest and then switching to 10.1.3.2
> - (580531) and running it again causes the exception :
> C:/kmarsden/repro/10447] java GetSchemas
> xception in thread "main" java.lang.NoSuchMethodError:
> org.apache.derby.iapi.sql.execute.ResultSetFactory.getBulkTableS
> anResultSet(Lorg/apache/derby/iapi/sql/Activation;JILorg/apache/derby/iapi/services/loader/GeneratedMethod;ILorg/apache
> derby/iapi/services/loader/GeneratedMethod;ILorg/apache/derby/iapi/services/loader/GeneratedMethod;IZ[[Lorg/apache/derb
> /iapi/store/access/Qualifier;Ljava/lang/String;Ljava/lang/String;ZZIIIZIIZDDLorg/apache/derby/iapi/services/loader/Gene
> atedMethod;)Lorg/apache/derby/iapi/sql/execute/NoPutResultSet;
> at
> org.apache.derby.exe.ac05550069x011dx254bxcb49x000000134c780.fillResultSet(Unknown
> Source)
> at
> org.apache.derby.exe.ac05550069x011dx254bxcb49x000000134c780.execute(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:326)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:377)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1123)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1335)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:244)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getSimpleQuery(EmbedDatabaseMetaData.java:3086)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getSchemas(EmbedDatabaseMetaData.java:1641)
> at GetSchemas.main(GetSchemas.java:9)
> import java.sql.*;
> public class GetSchemas {
> public static void main(String[] args) throws Exception{
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
> Connection conn =
> DriverManager.getConnection("jdbc:derby:wombat;create=true");
> DatabaseMetaData dbmd = conn.getMetaData();
> ResultSet rs = dbmd.getSchemas();
> while (rs.next()) {
> System.out.println(rs.getString(1));
> }
> }
> }
> Apparently the method signature changed but I thought the stored prepared
> statements recompiled whenever you changed versions so would not have such
> problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
