专利汇可以提供Data migration between versions of software专利检索,专利查询,专利分析的服务。并且A system and method are used for updating software to include new versions of the software without losing the ability to return to the prior software in the event of flaws or deficiencies in the new version. A framework organizes conversion and reversion codes into major components responsible for conversion of the data entities. The components are ordered based on their dependence on other components first completing their conversions. Each component implements an interface allowing a framework to process sequentially through all components and sequentially retrieve handles for their respective entities, and accessing the version of the entity. The framework processes an ordered set of interfaces representing the conversion/reversion, checks for progressively newer versions. As data structures are changed for a single component, a new version is appended to that component's ordered set of version interfaces. Restart of a conversion or reversion following an interrupt is also provided.,下面是Data migration between versions of software专利的具体信息内容。
What is claimed is:
The present invention relates to the conversion and reversion of various categories of logical entities created by an earlier release of software to a subsequently released version, and to the reversion to the earlier release.
New versions of software are constantly being created, and sometimes users wait through multiple versions before upgrading or converting to a more current iteration of the software. The user may also demand the ability to return or revert to the old version of the software if they discover a problem after use for a period of time. This multiple version conversion and reversion process becomes more complicated with each new release. Much of the updating may need to be done manually, often involving time consuming procedures. Newer software packages are able to make the upgrades without requiring manual steps. Nevertheless, because of this complexity, the recovery from system failures during the reversion process is limited to restoring the data files from archive, and starting over with the conversion.
In the case of a server, such as the IBM Informix Dynamic Server (IDS), (described in more detail at www-306.ibm.com/software/data/informix/ids., the entire contents of which is incorporated herein), multiple databases are hosted by the server, each database having its own system catalog. The implementation of a conversion typically requires development to keep growing a small set of files with new functions, and modifying a common set of utility functions with new code that is conditionally executed. The version information is finally updated when the final version is reached. Because of the large number of changes that are required during conversion, long transactions must be prevented by breaking them up into multiple transactions. This, in turn, leads to thousands of states that were not clearly identifiable. In the event of a system failure, recovery and restart are rendered difficult, if not impossible. Failure requires reload from backup (if available), and starting over.
To facilitate the understanding of the present invention, the following terms have the definitions as follows unless clearly contraindicated within the body of the specification.
The present invention covers conversion of various categories of logical entities created by an earlier release of software, to the latest version. It also covers the reversion of various categories of logical entities, from the latest version to a specified earlier version.
The invention allows restartability, and simplifies the implementation of upgrade code to support multiple starting points.
The invention also allows for conversion code from the previous release to remain unmodified and, therefore, less likely to be broken when adding additional conversion/reversion code.
The present invention is a framework that generalizes the conversion and reversion processes. It organizes the conversion and reversion code into major components responsible for conversion of the data entities. Further, these components are ordered based on their dependence on another major component having completed its conversion work, where the independent component comes first.
Each component implements an interface, allowing a framework process through all components sequentially, and sequentially retrieve handles for their respective entities, and accessing the version of the entity. It also allows the framework to process an ordered set of interfaces representing the conversion, reversion, and pre-reversion checks for progressively newer versions. As data structures are changed for a single component, a new version is appended to that component's ordered set of version interfaces.
The invention relates to a system and a method for converting various categories of logical data entities of a previous software release to an update of the logical entities and for the reversion of the logical entities to the previous release. This includes the following steps.
A conversion code and a reversion code are provided for each logical data entity. The conversion and reversion codes are organized into major components responsible for conversion of the logical data entities. These components are then arranged into a priority of dependencies. Then, the conversion of independent components is completed before proceeding with the conversion of dependent components. The method and system have the ability to stop the updating at multiple locations of the conversion procedure, and for restarting the update at the location where the update has stopped. By preserving the conversion code from a previous software release, it remains possible to revert to the previous release in the event there is trouble with the conversion.
The major components are ordered according to their dependency on completion of a conversion task by other major components, with the conversion of independent components occurring before the conversion of components dependent on the independent components. The invention has the ability to convert or revert from one size platform to a platform having a smaller or larger size by first moving to the target platform within the same server version or the first successor server version having compatible conversion semantics, and then proceeding to the target version. For example, a conversion may be between a 32 bit platform and a 64 bit platform.
The invention also relates to a system and a process for the conversion of categories of logical data entities from a previous software release to an updated release, for the reversion of logical entities to the previous release, and for the restart of a conversion or reversion that has been interrupted. The conversion/reversion/restart utilizes a component manager to manage multiple data entities and to conduct the conversion and reversion for said data entities. A state machine is instantiated by a framework façade to start the conversion for the component manager and instructs the component manager to iterate through all data entities that it manages. The components are arranged into a priority of dependencies. The conversion or reversion of independent components proceeds before the conversion or reversion of dependent components, and the conversion of major dependent components is completed before the conversion of minor dependent components.
The conversion state machine instructs the component manager to perform legacy checks of previous software releases for each entity. The component manager has several capabilities including performing parallel conversions for the simultaneous handling of multiple entities; determining if each entity requires conversion; and iterating through its set of versions of the software release before and after conversion. Another state machine is used for the reversion to a legacy or previous software version, and a third state machine is used for the restart of an interrupted conversion or reversion.
The drawings are presented to facilitate the understanding of the present invention without intending to limit the scope thereof. These drawings are briefly described as follows:
The high level design shown in
Within the conversion/reversion framework 10 are shown the conversion state machine 12, the reversion state machine 14 and the restart state machine 16. A bilateral link 20 is established between the CRF 10 and a new data application 22. Likewise, a two way link 30 is established between the CRF 10 and the component managers 32 so that each of the state machines is capable of interacting with the managers. This link serves to log information and iterate the same through the managers and the entities, and also to validate and execute the conversion or reversion. Each of the component managers is responsible for managing specific component versions, thereby ensuring server integrity during the conversion or reversion. This responsibility includes interaction with the legacy CRF, transactions, and logging data. The legacy CRF 40 is shown with two functions—validation 42 and execution 44. The validation detects and then provides a complete listing of all of the compatibilities to address before executing the conversion or reversion. When this is done, the legacy CRF proceeds with execution. The entities under the control of the component managers 32 are represented in the entity store 60 by five entities identified as Type 1 entities 62, Type 2 entities 64, Type 3 entities 66, Type 4 entities 68, and Type N entities 70. These entities are persisting and are overlapping, showing their interdependencies. During a conversion or reversion, each individual entity type will be in a different phase of the change, depending on their interdependencies. Thus, the Type 3 entities 66 are shown as overlapping those entity types on either side. This means that this more independent type of entity must complete a specific aspect of the conversion before the more dependent entity types commence theirs. During reversion, the reverse is true with the more dependent entities completing reversion prior to the less dependent entities.
Turning now to the second drawing,
The narrow vertical boxes represent steps to be taken. They show time sequences, but are not necessarily time lines. From left to right in the diagram, they represent the sequential steps that are taken to carry out the conversion, and the comparative length of each step. The framework façade 110 instantiates the state machine 112. The application starts the conversion/reversion/restart operation on the Framework Façade. (For the remaining steps, we will assume the ‘conversion’ step, although ‘reversion’ would be the same, but the iteration order would be reversed.) The state machine iterates through the component managers 132 and starts the conversion operation for each component manager.
Each component manager performs any legacy checks (see box 140) and conversion operations. It is instructed to iterate through all entities (box 160) it manages. If parallel conversion is possible for the manager, additional entities may be simultaneously handled. For each entity, the manager is instructed to perform a check on the entity to determine if conversion is required. If conversion is required, then the component manager is instructed to iterate through its set of versions. For each version, it performs conversion checks for the entity. If the conversion is successful, the component manager is instructed to iterate through its set of versions again. For each version, the component manager performs the conversion operation on the entity, and the entity is persisted with the current version information.
When the iterations are completed, the following actions are taken:
The system of the present invention utilizes the following design factors listed as desirable (should) or vital (shall).
Starting Conversion, Reversion or Restart—The CRF supports re-startability upon crash while performing C/R.
The CRF of the present invention addresses idiosyncrasies of the prior art CRFs. These include maintainability of C/R code and semantics, and developers having to keep track of changes for all previously supported server permutations just to advance to the next server release. This leads to testing being very exhaustive as well, the server rendered unstable, the inability to restart on server crash during C/R, etc. Owing to the fragile nature of the earlier CRFs, the CRF of the present invention is robust and addresses all the pain points and stability of the new CRF.
Partial Conversion/Reversion
Restartable conversion/reversion is a feature of this new CRF. The server is restartable if conversion/reversion fails for some reason.—but this is not true of the prior art CRFs. The completed transactions cannot be rolled back in situations which involve multiple transactions in a conversion or reversion. So, there has to be another mechanism/framework in place to handle such scenarios.
Partial C/Rs can be particularly troublesome if their C/R data is not logged. The following cases show when a partial conversion might occur; in other words, when there is a crash during the conversion/reversion, thereby necessitating the C/R to be restarted.
Cases:
It is important when performing conversion/reversion to be aware of these cases and to categorize each step in their conversion process. If there are both conv—2 and conv—4 and no logging, then it is difficult to restart the conversion. If conv—4 is true and no logging, then it should be determined that conv—2 is not true. Some way of tagging the structure should be used to know whether or not conversion/reversion was run on it. This is easier to do for conversion since a tag field can be added if necessary. For reversion, tag fields cannot be added.
Some layers may pick up the logging for free from disk management, so separate logging is not an issue for that layer. However, transaction boundaries during C/R can still be a concern.
If both conv—2 and conv—4 are true, then it is important to log or else the C/R would not be restartable. When the “first” attempt at conversion is made, the logs must be empty—that is, nothing to redo/undo. Disk management layers checks this.
Crashes can be very troublesome for the support organization. The analysis of crashes is made much easier using the present invention. Upon crashing, the system should print out the values of the structures being converted and the step and conversion operation being performed. These can be stored in fixed locations and dumped in HEX.
Crashes are caused factors such as: (1) The conversion/reversion code itself due to an error in the code or an error in the input data. By merely rerunning the conversion/reversion, another crash is most likely. (2) Some other event which simply crashed the server. (3) Error in input data (corrupted storage).
Transactions
For restartable conversion/reversion, most people are using transactions to enforce this. Formalization of this concept is necessary to avoid programmers making mistakes.
Transactions have the problem that they might “go long”. That is, the transaction is so long it overflows the available log files. Long transactions are rolled back by the system automatically. When converting a long table, for example, whose length is arbitrary, it is difficult to be sure that log space is not exceeded. One possibility is to convert n number of rows and then perform a ‘commit’ work on this subunit of work. The critical point is that there must be some way of knowing at what point the conversion is interrupted, unless it is not important to remember this. If a crash occurs, it can be important to know where to start conversion again.
To remember where the last transaction occurred, the stopping point must be logged in the same transaction. When writing to some other location on disk, for example, it is difficult to restart the server reliably—even if the write is performed within the same transaction.
In some cases, there might be other ways to remember where the transaction left off, or other cases where it might not be important to know where the stopping point is. If copying a table contents to another table and then renaming that table to the original name, it might be easy to detect that the operation was not finished, and can simply be restarted.
The approach guidance for the iterative single-step C/R framework is based on the fundamental principle that it will be built on top of the existing CRF (with minimum re-factoring). The framework consists of three non-deterministic state machines (Convert (C), Revert (R) and Restart (Re)) which encapsulate appropriate logic. There are also component managers that interface with the framework and have component responsibility of validation and execution. Upon receiving a C/R/Re request, the framework will then instantiate and initialize the appropriate state machines. Each of the state machines will have a finite set of states and transitions based on its interaction with the component manager, server and handling exception scenarios.
The conversion/reversion framework has the responsibility to ensure the integrity of the state machines and log appropriately. The component managers manage all the activities within the component. Mandated component activities include, but are not restricted to:
The framework also supports restarts in the event of server crashes during C/R. This is supported by the restart state machine whose primary responsibility is to analyze the restart situation, scan the logs and work with component managers to determine the last ‘known’ committed state. The component branding helps determine the start point. The extensible log manager used by smart blobs should be used to aid the framework in this effort.
Each entity is represented by a component manager whose responsibilities are also listed. In order to interface with the framework, here are the basic typedefs which are the basis for binding the conversion/reversion framework to the components. These typedefs allow the framework to implement the generalized conversion/reversion logic, but call the component specific code.
All Callbacks will return a status to inform the framework of the results of the callback.
The strategy that is used for 32←→64 bit platform C/R and to handle situations where it is impossible to avoid putting in features in patch releases that have C/R impact is explained by the following example:
This depicts, first proceed with convert/revert to the target platform architecture version and then proceed with the C/R of the target server version.
Listed below are principles and mandates that govern the high level design architecture of the present invention.
It should be understood that the present invention can be realized in hardware, software, or a combination of the two. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software could be a general purpose computer system that, when loaded and executed, controls the computer system such that it carries out the methods described herein. The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which, when loaded in a computer system, is able to carry out these methods.
Computer program instructions or a computer program in the present context means any expression, in any language, code (i.e., picocode instructions) or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following occur: (a) conversion to another language, code or notation; (b) reproduction in a different material form.
While the invention has been described in combination with specific embodiments thereof, there are many alternatives, modifications, and variations that are likewise deemed to be within the scope thereof. Accordingly, the invention is intended to embrace all such alternatives, modifications and variations as fall within the spirit and scope of the appended claims.
标题 | 发布/更新时间 | 阅读量 |
---|---|---|
多功能电梯智能远程报警媒体机 | 2022-06-06 | 0 |
用于同时读取多个表格的系统和方法 | 2023-04-25 | 0 |
污水处理厂不停运扩能改造施工方法 | 2020-08-04 | 2 |
一种具有远程监控报警功能的船舶导航雷达 | 2020-12-06 | 1 |
眼睛温度的测量与分析系统、接收分析装置及其方法 | 2020-11-20 | 2 |
三维图像处理方法及实施该方法的便携式三维显示设备 | 2022-08-30 | 0 |
Composite application modeling | 2022-09-05 | 0 |
VOLTAGE LEAKAGE DETECTION FOR SERIALLY CONNECTED ELECTRICAL NODES IN A SEISMIC SURVEYING SYSTEM | 2022-02-04 | 0 |
Method for Extending an Embedded Software Component of a Field Device | 2021-03-06 | 2 |
SELF-CONTAINED CONFERENCE ROOM SYSTEM AND SERVICE | 2021-11-16 | 0 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。
专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。