Patent Application
20100088270
Embodiments of the invention relate generally to the software arts, and, more specifically, to a data versioning concept including time dependency and active and inactive states.
Versioning is a term used for the creation and management of multiple releases of a product, all of which have the same general function but are improved, upgraded or customized. The term applies especially for operating systems, software, and management of data.
Version control is a general term used for keeping track of different versions of electronic information. It also ensures collaborative data sharing and editing among users of systems that employ different versions of a product. It is most commonly used in engineering and software development to manage ongoing development of digital documents such as application source code, art resources such as blueprints or electronic models, and other projects. Version control systems are usually stand-alone applications.
There are multiple data versioning concepts. Some of them support active and inactive data versions but with the possibility of having only one active version at a point of time. The term “active” means that a particular version is used for any operational processing, while inactive data is used only for modeling. Temporary or incomplete data cannot be used for operational processing. Although, there is always only one active version, there may be several inactive versions. A user may decide to activate one version and by doing so, to inactivate the previously active version. Thus, there cannot be multiple active versions and the user can process only the current active version.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
A computing system and method for data versioning with time dependency and active and inactive states are described. In one embodiment, the method includes creating a first version of an object in an application, wherein the application supports a versioning mode. The versioning mode maintains a set of versions of an object. The method further includes activating the first version of the object at a first timestamp and activating a second version of the object at a second timestamp in the versioning mode switched on. The first timestamp and the second timestamp define a validity period of the first version. Finally, the first version of the object is provided upon a request, wherein the request includes a timestamp in the validity period of the first version.
In one embodiment, the system includes an application that supports a versioning mode, an object with a set of versions, and a database to store the set of versions of the object with versioning information, wherein the versioning information includes a validity period, a timestamp, and a version state. The version state indicates if a version from the set of versions is active or inactive. The system also includes a unit to switch from the versioning mode to a non-versioning mode in the application.
Embodiments of the invention relate to a method and a system for data versioning including time dependency and supporting states active and inactive.
Versioning of data is a powerful concept that allows users to track changes, keep and work on old versions of data, and manage a number of versions or a specific version upon a request. In one embodiment of the invention, the versioning concept can be implemented as an additional functionality, or unit, in a graphical user interface (GUI) of an application. This unit can be in the form of a button, tab, link, or any other GUI element that can be used to execute the versioning concept. The versioning concept can be switched on and off in the application. Thus, the user can decide which data to keep track of.
In addition, the versioning concept includes time dependency. Each version of a data object is created and activated with a timestamp. Thus, the user can access older versions of the object by providing a timestamp. In one embodiment of the invention, the versioning concept may be used for maintaining history of data.
At some point of time, the user decides to change the value of the object “ABC” to “XYZ”. Upon this change, version_B 140 is created. Version_B 140 of the object is activated at timestamp_B 145 (for example, 2008.06.23-03.10.18). Version_B 140 is active until version_C 150 is created and activated. Version_C 150 is activated at timestamp_C 155 (for example, 2008.07.13-05.04.00). If no other version is activated, version_C 150 is valid until eternity 180.
At timestamp_D 165 (for example, 2008.07.24-03.15.48), the user changes the value of the object to “LMN”. A new version_D 160 is created. The user saves the version but does not activate it. Version_D 160 is inactive until the user activates it.
The creation of the versions of the object is briefed in the following table.
Referring back to
The versioning concept processes activated versions and the last active version (e.g. version_C) is valid until eternity 180 as long as no further version is activated. Activation of a version does not mean that a save operation to a database is performed. Changes on the object will be saved to a database only upon a save operation. The versioning concept provides a possibility for an application to process activated versions even if they are not saved.
In one embodiment of the invention, the user request may not include any timestamp. If the request is to process the object, for example, to execute a rule or a set of rules on the object, then the versioning concept will return the last activated version of the object (e.g., version_C). If the request is to maintain the object, for example, to create a set of rules, the versioning concept will display the properties of the last saved version (e.g., version_D). In addition, the versioning concept can keep track of properties such as names of objects, texts, short texts, and so on.
The versioning concept includes two methods that provide the user with more information about the versions of a particular object. The first method is called “GET_VERSIONS”. This method returns a table with specific details about all versions existing for a particular object. This method may also provide the last version that has been saved to a database. The second method is called “GET_ACTIVE_VERSION”. This method returns the last activated version of an object.
At block 320, some changes are performed on version_1 of the object. These changes may include, but are not limited to, changing the value of an object, changing the text describing the object, and so on. Upon the performed changes, a second version of the object is created (e.g., version_2). The second version is initially inactive and located in a temporary storage. At block 325, version_2 is activated. Because the versioning mode of the application is switched off, all new active versions are copied back to the first active version created in non-versioning mode. Thus, version_2 overwrites version_1 and version_2 is also deleted from the temporary storage. In case there is not a version created in the non-versioning mode (i.e., version_1 does not exist), a new active version is created. Copying back versions also implies that an inactive version with a number, active version number+1, is deleted from the database. Therefore, version_2 is copied back to version_1 and, if version_2 was saved to the database prior to the activation, it is also deleted from the database. Thus, only version_1 exists and stays as active.
At block 330, the versioning mode in the application is switched on. Some changes are performed on version_1 at block 340. Upon the performed changes, a new second version of the object is created (e.g., version_2). At block 345, version_2 is activated and saved to the database. The versioning mode is switched off at block 350. At block 355, additional changes are performed. Upon the performed changes, a third version of the object is created (e.g., version_3). At block 360, version_3 is activated. Version_3 is the first active version created in non-versioning mode. At block 365, some changes are performed on version_3. The last changes create a forth inactive version of the object, version_4. Version_4 overwrites version_3, thus version_3 contains the last changes. No other active versions can be created in the non-versioning mode. Any new changes will be copied back to the first active version in the non-versioning mode, i.e., version_3.
When a new version of an object is activated, excluding the first version, the upper border of the previous version is set to meet the lower border of the new active version. For example, version_2 begins exactly at the moment where version_1 ends and version_2 ends at the moment version_3 is activated. The new active version is valid until eternity or until another new version is activated. Thus, there are no time gaps between the active versions.
The time period during which a version was active is defined as a validity period. For example, for version_2, the validity period is from timestamp t2.3 to t3. Therefore, if a user sends a request and the request includes a timestamp in the validity period of version_2, then version_2 will be returned to the user. If the user sends a request without a timestamp, the returned version will be version_3, in case the request is to process the object. Otherwise, if the request is to maintain the object, then version_4 will be returned.
Each saved object is stored in a database table with a key, a value, and versioning information. The versioning information may include, but is not limited to, a validity period, a version state, and a timestamp. There can be several data sets for several versions of one object. In an embodiment, these several versions may be all active at the same time. In another embodiment, these versions may be all inactive at the same time.
Elements of embodiments may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, embodiments of the invention may be downloaded as a computer program, which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
In the foregoing specification, the invention has been described with reference to the specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
