Mamta Satoor wrote: Thanks for the patch. I looked mainly at the soft/hard upgrade code.
- Good to add comments to the upgrade code you added in DD_Version.doFullUpgrade. I'd assumed it was incorrectly using DD_VERSION_THIS_SOFTWARE_VERSION instead of DD_VERSION_DERBY_10_2, but I think this is the generic upgrade code you mention in the jira comments. Though why do you need to check the version at this point, the higher code has decided that a full upgrade is required? - In EmbedDatabaseMetaData.notInSoftUpgradeMode the comments about 'not changing the system tables' I think are misleading. I think you mean the stored versions of the JDBC database meta data queries. To me, changing the system tables means things like adding a column to a system table. - DataDictionary.DD_VERSION_THIS_SOFTWARE_VERSION - there was already a mechanism to check that the database had been upgraded to the current verion, using checkVersion with DataDictionary.DD_VERSION_CURRENT. Thus this new field can be removed. (I think). - The new method LanguageConnectionContext.prepareInternalStatement, is the fourth parameter really 'forMetaData' or more generically 'allowInternalSyntax'? I've spent time over the last two years trying to decrease the number of prepare methods in the code, so I'm not thrilled to see a new one. Especially as it's probably only used for meta-data, so the last two parameters are fixed 'true, true', thus if you wanted a prepared for meta-data only method, you could get away with a two argument one, maybe even one as the schema descriptor should not be required. This additional prepare method comes out of the soft upgrade code for database meta data, I'd like to try and spend some time before Sat seeing if there's an alternative. I thought there was some code to already handle this type of case which would mean no changes to EmbedDatabaseMetaData were required. I think this patch also addresses DERBY-727, add the upgrade framework. Dan.
