Downgrading database software via a downgradability test
Abstract
Techniques for downgrading of database software. Code areas that may affect downgradability may be delineated with code markers. Changes to these sections can be made to prevent a new database version from being built unless a process is taken to indicate that any new features be designated as available, but not yet allowed for N software releases. This provides a downgrade window of N releases that will support functionality currently allowed by the database. In response to receiving a downgrade request to a target older database software version, that request can be permitted if all the database features are available or allowed in the target version. If at least one of the database features is not available in the target version, the downgrade requested is not permitted. If the request is permitted, the downgrade operation is commenced.
Claims
exact text as granted — not AI-modifiedWhat is claimed is:
1. A non-transitory, computer-readable hardware storage medium storing program instructions that are capable of being executed on a computer system to perform operations that comprise:
receiving a request to perform a downgrade from a current version of database software to an older, target version of the database software, wherein the database software is executable to interface with a database;
performing a downgradability test that includes:
determining a first set of features that have been allowed for the database;
determining a second set of features that are indicated as available or allowed in the target version of the database software; and
determining whether the target version of the database software is compatible with a current state of the database by assessing whether all of the first set of features are included in the second set of features;
responding to the request based on a result of the downgradability test by initiating the downgrade of the current version of the database software or denying the request to perform the downgrade of the current version of the database software; and
preventing use of a new feature in the database software until after N releases in which the new feature is available but is not yet allowed to make changes to the database, thus providing a downgrade window that includes N versions of the database software to which to downgrade at a given point in time with respect to the new feature.
2. The non-transitory, computer-readable hardware storage medium of claim 1 , wherein initiating the downgrade of the current version of the database software is performed in response to the downgradability test determining that all of the first set of features are included in the second set of features; and wherein denying the request to perform the downgrade of the current version of the database software is performed in response to the downgradability test determining that one or more of the first set of features are not included in the second set of features.
3. The non-transitory, computer-readable hardware storage medium of claim 2 , wherein the downgrade of the current version of the database software is performed using a software routine that permits a transition from a first version of the database software to a second version of the database software, whether the transition is an upgrade or a downgrade.
4. The non-transitory, computer-readable hardware storage medium of claim 2 , wherein the downgrade of the current version of the database software is performed by:
creating a shadow catalog;
importing contents from a catalog of the database into the shadow catalog; and
switching over from 1) using the current version of the database software and the catalog of the database to access the database to 2) using the target version of the database software and the shadow catalog to access the database.
5. The non-transitory, computer-readable hardware storage medium of claim 1 , wherein the operations further comprise:
in response to detecting a difference in a checksum value associated with a protected area of the database software into which a change is made, initiating a change update process in which:
a feature setting file is amended to indicate that the change is in an available state; and
the feature setting file is later updated to indicate that the change is allowed after N releases in which the change is included.
6. The non-transitory, computer-readable hardware storage medium of claim 5 , wherein a new release of the database software is prevented from being built unless the change update process is begun, and wherein the downgradability test checks the feature setting file in order to determine the second set of features.
7. A method for determining whether to permit downgrading of database software, the method comprising:
receiving, by a computer system, a request to perform a downgrade from a current version of database software to an older, target version of the database software, wherein the database software is executable to interface with a database;
accessing, by the computer system:
a first set of features that have been allowed for the database; and
a second set of features that are indicated as available or allowed in the target version of the database software;
determining, by the computer system, whether the target version of the database software is compatible with a current state of the database based on a comparison of the first set of features to the second set of features; and
responding, by the computer system, to the request based on the determining by initiating the downgrade of the current version of the database software or denying the request to perform the downgrade of the current version of the database software; and
wherein the target version of the database software is defined to be compatible with the current state of the database in response to the target version of the database software being one of N previous releases of the database software, and wherein N is a defined downgrade window.
8. The method of claim 7 , wherein the first set of features includes a particular feature relating to a schema of the database.
9. The method of claim 8 , wherein the target version of the database software includes a first code portion executable to access the database using an older version of the particular feature and a second code portion executable to access the database using a newer version of the particular feature, and wherein the first code portion, but not the second code portion, is enabled in the target version of the database software as default behavior with respect to the particular feature.
10. The method of claim 9 , wherein the current version of the database software includes the first code portion and the second code portion, and wherein the second code portion, but not the first code portion, is enabled in the current version of the database software as default behavior with respect to the particular feature; and
wherein the target version of the database software is downgrade-compatible with the current state of the database with respect to the particular feature.
11. The method of claim 7 , wherein responding to the request includes:
initiating the downgrade of the current version of the database software in response to determining that all of the first set of features are included in the second set of features.
12. The method of claim 11 , wherein the downgrade of the current version of the database software is performed using a software routine that permits a transition from a first version of the database software to a second version of the database software, whether the transition is an upgrade or a downgrade.
13. The method of claim 7 , wherein denying the request to perform the downgrade of the current version of the database software is performed in response to determining that one or more of the first set of features are not included in the second set of features.
14. The method of claim 7 , further comprising:
preventing a version of the database software from being built in response to detecting that a change has been made to a downgrade-sensitive portion of code of the database software without beginning a change update process in which:
a feature setting file is amended to indicate that the change is in an available state; and
the feature setting file is later updated to indicate that the change is allowed after N releases in which the change is included.
15. A computer-implemented method, comprising:
detecting a code change to a downgrade-sensitive portion of code of database software that is executable to interface with a database, wherein a new feature corresponding to the code change replaces an old feature;
in response to detecting the code change, preventing a build of a release of the database software until the new feature is registered as having an available state;
in response to the new feature being registered as available, building the next N versions of the database software to:
include a first code portion implementing the old feature and a second code portion implementing the new feature; and
enable the first code portion, but not the second code portion;
after the next N versions of the database software include the new feature, changing registration of the new feature from the available state to an allowed state such that successive versions of the database software are built to enable the second code portion, but not the first code portion;
receiving a request to perform a downgrade from a current version of the database software to an older, target version of the database software;
determining whether to permit the request based on whether a first set of features that have been allowed for the database are indicated as either available or allowed in a second set of features corresponding to the target version of the database software; and
responding to the request based on the determining by initiating the downgrade of the current version of the database software or denying the request to perform the downgrade of the current version of the database software.
16. The computer-implemented method of claim 15 , wherein detecting the code change includes detecting a difference in a checksum value associated with a protected area of the database software into which the code change is made.
17. The computer-implemented method of claim 15 , wherein responding to the request includes initiating the downgrade of the current version of the database software in response to determining that all of the first set of features are included in the second set of features.
18. The computer-implemented method of claim 15 , wherein the determining prevents use of the new feature in the database software until after N releases in which the new feature is available but is not yet allowed to make changes to the database, thus providing a downgrade window that includes N versions of the database software to which to downgrade at a given point in time with respect to the new feature.
19. A method for determining whether to permit downgrading of database software, the method comprising:
receiving, by a computer system, a request to perform a downgrade from a current version of database software to an older, target version of the database software, wherein the database software is executable to interface with a database;
accessing, by the computer system:
a first set of features that have been allowed for the database, wherein the first set of features includes a particular feature relating to a schema of the database; and
a second set of features that are indicated as available or allowed in the target version of the database software;
determining, by the computer system, whether the target version of the database software is compatible with a current state of the database based on a comparison of the first set of features to the second set of features; and
responding, by the computer system, to the request based on the determining by initiating the downgrade of the current version of the database software or denying the request to perform the downgrade of the current version of the database software; and
wherein the target version of the database software includes a first code portion executable to access the database using an older version of the particular feature and a second code portion executable to access the database using a newer version of the particular feature, and wherein the first code portion, but not the second code portion, is enabled in the target version of the database software as default behavior with respect to the particular feature.
20. A non-transitory, computer-readable hardware storage medium storing program instructions that are capable of being executed on a computer system to perform operations that comprise:
receiving a request to perform a downgrade from a current version of database software to an older, target version of the database software, wherein the database software is executable to interface with a database;
performing a downgradability test that includes:
determining a first set of features that have been allowed for the database;
determining a second set of features that are indicated as available or allowed in the target version of the database software; and
determining whether the target version of the database software is compatible with a current state of the database by assessing whether all of the first set of features are included in the second set of features;
responding to the request based on a result of the downgradability test by initiating the downgrade of the current version of the database software or denying the request to perform the downgrade of the current version of the database software; and
in response to detecting a difference in a checksum value associated with a protected area of the database software into which a change is made, initiating a change update process in which:
a feature setting file is amended to indicate that the change is in an available state; and
the feature setting file is later updated to indicate that the change is allowed after N releases in which the change is included.Cited by (0)
No later patents cite this yet.
References (0)
No backward citations on record.