db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "MetadataUpgrade" by KnutAndersHatlen
Date Tue, 25 Apr 2006 14:28:02 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by KnutAndersHatlen:
http://wiki.apache.org/db-derby/MetadataUpgrade

------------------------------------------------------------------------------
  
  == Maintenance and Point Releases ==
  
+ Currently, there is no mechanism for handling changes in metadata
+ queries between maintenance releases or point releases (third and
+ fourth digit in the version number). Since new features require a new
+ minor version, metadata changes between maintenance/point releases
+ must be bug fixes only.
  
+ There are essentially three ways of handling metadata changes between
+ maintenance/point releases:
  
+   1. By dropping and recreating the stored prepared statements on every version change.
+   1. By making Derby run in soft upgrade mode when the version changes.
+   1. By adding special upgrade code when the need arises.
+ 
+ Option 1 and 2 will make the queries work as they should when moving
+ to a newer version, and they will revert to the old behaviour when
+ going back to the older version. The down side of these solutions is
+ performance. Option 1 requires recreation and recompilation of all
+ stored statements, even when they have not changed. Similarly, option
+ 2 forces soft upgrade for all version changes, even when no changes
+ have been made to the metadata queries.
+ 
+ Adding special upgrade code when the need arises solves the
+ performance problems for the normal case where no metadata changes
+ have been made. There are many ways to do this, for instance
+ 
+   * Dropping and recreating SPSs when moving to a version where the metadata queries have
changed. This ensures that the new queries are used when moving to a newer version. It does
however not ensure that the old query is used when moving back to the old version. This might
actually not be a bad thing, since metadata changes between maintenance releases most likely
are bug fixes. The query must be backwards compatible, otherwise moving back to the old version
is impossible.
+   * Enabling soft upgrade mode when moving to a version where the metadata queries have
changed. This solves the problem of the query not being reverted when reverting the version.
However, the performance is lower.
+   * Creating new metadata queries with new names. Instead of modifying the old query, one
can create a new one with a new name (for instance by appending a version number). When moving
from an older version, the new query has to be created, but the old query is kept in the database.
This way, the old query is still there when moving back to the old version.
+ 
+ Note that all of these solution, except those enabling soft upgrade
+ mode, will cause problems for read-only databases. For read-only
+ databases, one either has to enable soft upgrade mode or continue
+ using the old metadata queries.
  
  == Client/Server Mixed Version Metadata Negotiation ==
  With new features !DatabaseMetaData calls will potentially need to be "negotiated down"
if the client is older and cannot support the new feature.  There is no infrastrure in place
for this at this time and will have to be implemented as the need arises.

Mime
View raw message