Version History Data Container for Efficient Query Evaluation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current systems face inefficiencies in locating ancestors and descendants of a given version in a version history within a repository that supports versioning of resources, which is crucial for data-oriented access and visualization.
Innovation Solution
A version history data container is implemented, storing records with predecessor and successor identifiers, and rowsets to efficiently track and retrieve ancestor or descendant versions, allowing for recursive index scans to build version history trees without overloading buffer cache memory.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If version history data is stored in a separate table from resource data, then query efficiency for version histories is improved, but system complexity increases
Solution Approach 1:
The patent divides the version control system into two separate tables: a resource table storing file metadata and a version history table storing version-specific data. This segmentation allows independent optimization of each table for its specific access patterns, improving query efficiency while managing complexity through clear separation of concerns.
Solution Approach 2:
The version history table acts as an intermediary structure between the resource table and the version history queries. It pre-computes and stores ancestor/descendant relationships, serving as a mediator that translates complex version history traversal requirements into efficient database queries without overloading the buffer cache.
2Loss of information
If multiple table scans are performed to locate ancestors and descendants, then complete version history information is retrieved, but processing overhead increases
Solution Approach 1:
The system performs preliminary actions by pre-computing and storing ancestor and descendant relationships in the version history table during version creation. This allows query operations to retrieve pre-prepared information through efficient index scans rather than performing multiple sequential table scans at query time, significantly reducing processing overhead while maintaining complete version history information.
3Quantity of substance
If version history queries are evaluated using traditional methods, then all version information can be accessed, but buffer cache memory becomes overloaded
Solution Approach 1:
The patent extracts version history-specific data and relationships from the general resource table into a dedicated version history table. This extraction allows version history queries to operate on a smaller, specialized table that can be efficiently cached in buffer memory, reducing the memory footprint and preventing buffer cache overload while maintaining full access to version information.
Data Source
AI summary
Efficient evaluation of resource version history queries is enabled by using a data container storing records corresponding to links between successive versions of a resource. The records include: (a) a record identifier, (b) a predecessor identifier, (c) a successor identifier, (d) a predecessor rowset, which comprises the record identifier of each record in which the predecessor identifier in this record is the successor identifier, and (e) a successor rowset, which comprises the record identifier of each record in which the successor identifier in this record is the predecessor identifier. Depending on the nature of a request, a record is identified in which a particular version is identified by either the predecessor identifier or the successor identifier. Either the predecessor or successor rowsets are recursively read, while the predecessor or successor identifiers corresponding to each record read are added to a result set, thereby forming the ancestor or descendant version history.