Create guidelines for removing/deprecating config

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Documentation
    • None
    • Storage Engines, Storage Engines - Foundations
    • None
    • None

      During a recent look back at some HELP tickets (listed in the comments), we collectively decided that we could do with some guidelines around removing config items.

      Broadly, WiredTiger aims to be able to read any database created by an older version. There was one deliberate compatibility break with durable history, but (as far as I know) that's all.

      Config items are in a related, but slightly different boat. It's different to say "this feature was removed in version X and is no longer supported" as opposed to "this entire DB needs to be rewritten in a newer format before we can read it".

      As such, we have removed features (custom extractors, LSM, FLCS) that could theoretically render some databases unreadable.

      We should codify what can be removed, and when – for example, when removing custom extractors, we removed the ability to parse empty config strings for the feature (e.g. ...,extractor=,...) which unnecessarily broke some databases. So we can't fully remove config that persists to metadata, and this needs to be documented.

            Assignee:
            [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            Will Korteland
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: