Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-63

Unversioned updates on the WORM Journal

    Details

    • Type: Task
    • Status: Done
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Journal

      Description

      I would like to know what it would take to be able to apply unversioned updates to a WORM Journal. The use case is preserving the ability to read the historical state of an index when an upgrade applies a change to the IndexMetadata object, e.g., replacing the ITupleSerializer field. Because the AbstractBTree is loaded from a Checkpoint record, historical reads will continue to access the old IndexMetadata object. This would require backward compatibility in the code after the upgrade in order to read both historical data and data written after the upgrade.

      What I have in mind is something along the lines of replacing the bytes in the checkpoint record such that they now point to the new IndexMetadata objects for all historical commit points.

        Activity

        Hide
        martyncutcher martyncutcher added a comment -

        The core problem of accessing a checkpoint record, retrieving the address of the IndexMetaData, reading the old IndexMetaData, converting to the new IndexMetaData, saving it to the Journal and then updating the address in the original record is an understandable enough process. Such an upgrade approach for certain key data structures could remove the problem of providing support for multiple historical versions which could become exponentially complex if dependent substructures also were affected.
        It may be that we could identify a set of these core classes and consider a pattern to better isolate the system from such problems in the future, for example by using specific version state serializers to remove the transient system class from a serialization dependency, enabling more flexibility when refactoring.

        Show
        martyncutcher martyncutcher added a comment - The core problem of accessing a checkpoint record, retrieving the address of the IndexMetaData, reading the old IndexMetaData, converting to the new IndexMetaData, saving it to the Journal and then updating the address in the original record is an understandable enough process. Such an upgrade approach for certain key data structures could remove the problem of providing support for multiple historical versions which could become exponentially complex if dependent substructures also were affected. It may be that we could identify a set of these core classes and consider a pattern to better isolate the system from such problems in the future, for example by using specific version state serializers to remove the transient system class from a serialization dependency, enabling more flexibility when refactoring.

          People

          • Assignee:
            martyncutcher martyncutcher
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: