limber-timber 0.0.1__py3-none-any.whl

limber_timber-0.0.1.dist-info/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Daniel Tashjian
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

limber_timber-0.0.1.dist-info/METADATA

@@ -0,0 +1,318 @@
+Metadata-Version: 2.3
+Name: limber-timber
+Version: 0.0.1
+Summary: Database Migrations Made Easy
+License: MIT
+Author: Daniel Tashjian
+Author-email: thewopple@gmail.com
+Requires-Python: >=3.10
+Classifier: Development Status :: 2 - Pre-Alpha
+Classifier: Framework :: Pydantic :: 2
+Classifier: Framework :: Pytest
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Requires-Dist: devtools (==0.12.2)
+Requires-Dist: google-cloud-bigquery (==3.34.0)
+Requires-Dist: pydantic (==2.11.4)
+Requires-Dist: pyyaml (==6.0.2)
+Project-URL: Homepage, https://github.com/Wopple/limber-timber
+Project-URL: Repository, https://github.com/Wopple/limber-timber
+Description-Content-Type: text/markdown
+
+Limber Timber
+=============
+
+***Database Migrations Made Easy***
+
+## Overview
+
+This project is not ready for production use, consider it v0.0.0.
+
+I am writing the migration system I always wanted but does not exist (yet).
+
+## Notable Feature Goals
+
+- Migrations specified in data, not SQL
+- Down migrations automatically inferred from up migrations
+  - Yes, down migrations for drop table and drop column are automatically inferred
+- Separation of database and metadata
+- In-memory support
+- Database adoption
+- No checksums
+- Manifest instead of numbered or timestamped migration filenames
+- JSON schema for migration files
+- Error recovery for backends that do not support DDL transactions
+
+## Not Goals
+
+- ORM
+- Parsing SQL
+- Specifying all kinds of migrations in pure data (e.g. DML migrations will use SQL)
+- Preserving lost data
+
+## Rationale
+
+- It is cumbersome to iterate on migrations without robust down migrations
+- Automatically inferred down migrations reduces developer burden
+- Writing migrations in data is cleaner and not specific to a database
+- Never parsing SQL reduces the complexity of the codebase
+- A lightweight open source library makes it each to add missing features
+- JSON schema allows IDEs to be configured for migration file validation and auto-completion
+- Separation of database and metadata allows for more flexible metadata storage options
+- In-memory database and metadata allow for application unit testing
+- No checksums allows for modifying migration files without breaking the migrations
+- Manifest files cause git merge conflicts when parallel development has collisions
+
+## Roadmap
+
+These are listed in rough priority order if you are interested in contributing.
+
+- ✅ CLI
+- ➡️ Publish to PyPI
+- ➡️ Github Actions
+  - ➡️ Unit Tests
+  - ➡️ Release
+- ✅ In-memory Database
+- ✅ In-memory Metadata
+- ➡️ Big Query Database
+  - ✅ Create Table
+  - ✅ Drop Table
+  - ✅ Rename Table
+  - ✅ Set Table Partition Expiration
+  - ✅ Set Table Clustering
+  - ✅ Add Column
+  - ✅ Drop Column
+  - ✅ Rename Column
+  - ➡️ Alter Column
+  - ➡️ Create View
+  - ➡️ Create Materialized View
+  - ➡️ Create Snapshot Table
+  - ➡️ Create Table Clone
+  - ➡️ Labels
+  - ➡️ Options
+- ✅ Big Query Metadata
+- ➡️ Database Adoption
+- ➡️ JSON Schema
+- ✅ Database Specific Validation
+- ➡️ Templating
+- ➡️ Expand Grouped Operations
+- ➡️ Grouped Operation Application
+- ➡️ Minimize Scan Output
+- ➡️ Arbitrary DML SQL Migrations
+- ➡️ File System Metadata
+- ➡️ SQLite Database
+- ➡️ SQLite Metadata
+- ➡️ Postgres Database
+- ➡️ Postgres Metadata
+- ➡️ MySQL Database
+- ➡️ MySQL Metadata
+
+## Usage
+
+### Create Migrations
+
+1. Create your target manifest
+
+> Note: All migration files can use any of these extensions:
+> - `.json`
+> - `.yaml`
+> - `.yml`
+
+Create a target directory with a manifest file named `manifest.yaml`.
+
+```yaml
+# target_dir/manifest.yaml
+version: 1
+operation_files:
+- path/to/create_user_table.yaml
+- path/to/enrich_user_name.json
+```
+
+2. Create your target migration operations
+
+> Tip: Using a subdirectory for the operations files makes it easy to configure your IDE to apply the correct JSON schema.
+
+Create the files listed in your manifest.
+
+```yaml
+# target_dir/path/to/create_user_table.yaml
+version: 1
+operations:
+- kind: create_table
+  data:
+    table:
+      name:
+        database: your_project
+        schema_name: your_dataset
+        table_name: users
+      columns:
+      - name: id
+        data_type: INT64
+      - name: name
+        data_type: STRING
+```
+
+```yaml
+# target_dir/path/to/enrich_user_name.yaml
+version: 1
+operations:
+- kind: rename_column
+  data:
+    table_name:
+      database: your_project
+      schema_name: your_dataset
+      table_name: users
+    from_name: name
+    to_name: firstname
+- kind: add_column
+  data:
+    table_name:
+      database: your_project
+      schema_name: your_dataset
+      table_name: users
+    column:
+      name: lastname
+      data_type: STRING
+```
+
+3. Check what migrations will run
+
+```shell
+poetry run liti migrate \
+    -t target_dir \
+    --db bigquery \
+    --meta bigquery \
+    --meta-table-name your_project.your_dataset._migrations
+```
+
+4. Run the migrations
+
+```shell
+poetry run liti migrate -w \
+    -t target_dir \
+    --db bigquery \
+    --meta bigquery \
+    --meta-table-name your_project.your_dataset._migrations
+```
+
+### Scan Database
+
+You can also scan a schema / table which will print out the operations file that generates that schema / table.
+
+```shell
+# scan a schema
+poetry run liti scan \
+    --db bigquery \
+    --scan-database your_project \
+    --scan-schema your_dataset
+```
+
+```shell
+# scan a table
+poetry run liti scan \
+    --db bigquery \
+    --scan-database your_project \
+    --scan-schema your_dataset \
+    --scan-table your_table
+```
+
+## Learn
+
+Being completely new to this project, you will have no idea where to start. Here. This is where you start. This is a
+crash course on what Limber Timber is and how its put together.
+
+### The Big Picture
+
+Limber Timber uses the `Operation` to describe changes to a database. These operations are pure data. They can be
+serialized to JSON or YAML, and can be deserialized from the same. Developers write JSON or YAML files to describe the
+migrations for their application.
+
+The `Operation` can be enhanced to become an `OperationOps`. This type brings behavior to the data. It allows you to:
+- check if the operation has been applied to the database
+  - useful for recovery from a failure between applying an operation and writing it to the metadata
+- apply the operation, i.e. the "up" migration
+- produce the inverse `Operation` that will perform the "down" migration
+
+Down migrations are inferred from the up migrations, so developers only ever have to write the up migrations.
+
+### Migration Files
+
+Migration files start with a manifest file. The manifest points to the operation files in the order they should be
+applied. Each operation file contains a list of operations in the order they should be applied. In this way,
+```
+# file1
+[op1, op2]
+
+# file2
+[op3]
+```
+is exactly the same as:
+```
+# file1
+[op1]
+
+# file2
+[op2, op3]
+```
+
+The migrational unit is the `Operation`, not the file. Grouping operations into files can help for organization, but
+having a single file with all operations or many files each with one operation are both valid. There are no checksums
+and no need to specially name your files. You can also organize your migrations with sub-directories, just specify the
+paths in the manifest.
+
+One major benefit to this system is if parallel developers add operations, one will merge first, and then the other will
+get a merge conflict. This is much better than having migrations applied out of order (or breaking) after the fact. You
+learn right away about the conflict, and the developer is prompted to resolve it. This benefit assumes all developers
+are using the same style for adding new migrations: either adding a new file to the manifest, or adding a new operation
+to the most recent file.
+
+### Python Modules
+
+`liti.core.model`
+
+This module stores all the data models. The models are versioned, though currently there is only the one version. The
+hierarchy is roughly:
+
+> `operation.ops` > `operation.data` > `schema` > `datatype`
+
+`liti.core.model.v1.operation.data`
+
+These are the pure data operations. They are (de)serialized between the operation files and metadata.
+
+`liti.core.model.v1.operation.ops`
+
+These are the wrappers that enhance operations with behavior. There is a 1:1 relationship.
+
+`liti.core.model.v1.datatype`
+
+These are descriptions of column types.
+
+`liti.core.model.v1.schema`
+
+These are descriptions of tables and related constructs.
+
+`liti.core.backend`
+
+Both the database and the metadata can support different backends. You can even use different backends together. The
+backends deal in both the `liti` model and backend specific types adapting between the two.
+
+`liti.core.client`
+
+These are clients used by the backends. They solely deal in backend specific types with no dependencies on the `liti`
+model.
+
+`liti.core.base`
+
+This module has base classes for applying default values and validating the data. They are implemented using the
+Observer / Observable pattern so different backends can define their own behavior.
+
+`liti.core.runner`
+
+This module is for the runners associated with the various ways `liti` can be run. Main code will instantiate a runner
+and run it.
+

limber_timber-0.0.1.dist-info/RECORD

@@ -0,0 +1,29 @@
+liti/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
+liti/cli.py,sha256=ri3S3Os79mc3AhxUiIhYfyl3KqVtb-f9F1pbEDS7xxQ,6312
+liti/core/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
+liti/core/backend/__init__.py,sha256=Stp4fd7VAH8lGa1IpmdWM_s7YtTbB2DgtBct5Z0EmpU,30
+liti/core/backend/base.py,sha256=51XaUSbfUKco08pG1rJh9U8QInLlgxdCyPRZBGdJ43w,4337
+liti/core/backend/bigquery.py,sha256=d-gLx7M3ltWC-HWYJmo_9kG504r22QcmIinVqCQ361E,28133
+liti/core/backend/memory.py,sha256=g3uZjGlWKrXcrlDZEGHrgig836XQv4QL-U14p5mAEjI,4024
+liti/core/base.py,sha256=0IjpSQ1O6A8goOs0fDp4scaKZ9kVpGJKf7vANdHn08w,3101
+liti/core/client/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
+liti/core/client/bigquery.py,sha256=zOcoxAX8kWJAlWN43WDxBA0RLQAD8guFiXMtzzHSVj0,2859
+liti/core/function.py,sha256=eR2-R7ANH3rcmeZgGdxDfDNn403Z_bZxgjE4GpDIqgM,1911
+liti/core/logger.py,sha256=3KaHMDFEaPtBb1pm8Z6wi1_g3z6awoEB0lHp1jpc3OQ,1362
+liti/core/model/__init__.py,sha256=tAvk5TAXrOBe-LtXI2ACrHtf2ToHb0-bKtp3tv6NtcQ,112
+liti/core/model/v1/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
+liti/core/model/v1/datatype.py,sha256=af3SDwpvccSE_b2QSlYu4csLvZmia9k4PXP50WYbhpQ,5744
+liti/core/model/v1/operation/__init__.py,sha256=7Hsc7sa55_9CNh88f3cYVQ5ajNz5QxlY2g4bVDxjqmc,32
+liti/core/model/v1/operation/data/__init__.py,sha256=2cHyXVT2al6OvovrGdG8sldHJyrFChHbAhOPdy1c8ig,34
+liti/core/model/v1/operation/data/base.py,sha256=g1pSpPzaDYsCg2I-nyG-u8JsWkjnsTAbGzaMEVIi04A,559
+liti/core/model/v1/operation/data/table.py,sha256=LOOxBLQCTQI3Bg89xGRA5FAm2K6dmjwspo9NTgnE4JQ,2262
+liti/core/model/v1/operation/ops/__init__.py,sha256=g5_8xq7H8DFL_3y_rWQEh-RrpiXMjwqfHattbQIqkCc,105
+liti/core/model/v1/operation/ops/base.py,sha256=SDEl1bLapwQJOp8wRGph33ZjctoybASA8XI603xGqd0,1606
+liti/core/model/v1/operation/ops/table.py,sha256=64lgnBDpYzq7vPXQg_lcdLQTax8gVzUi7pLJzgvrb9w,10108
+liti/core/model/v1/schema.py,sha256=y6lxthDFJBv6BWAeYj999DR6M01y1z2FuqL4ebkMjcg,8385
+liti/core/runner.py,sha256=71Ph4rPQWjQ3j6a3z28b6H01XIENRex3VjX2npWuHzU,4806
+limber_timber-0.0.1.dist-info/LICENSE,sha256=jC5DbKlIWpMy35HUKaP-kNmm2I6d06vuu6g6G_S__zs,1072
+limber_timber-0.0.1.dist-info/METADATA,sha256=vtN6dpiXCcjihl_C9YFD-j2I--vEE3hIOj26HLk1_VE,9493
+limber_timber-0.0.1.dist-info/WHEEL,sha256=fGIA9gx4Qxk2KDKeNJCbOEwSrmLtjWCwzBz351GyrPQ,88
+limber_timber-0.0.1.dist-info/entry_points.txt,sha256=U0B88Tw-W_qi-xkHTbyb6kqQGpS30-6Cagneq8p6-jc,38
+limber_timber-0.0.1.dist-info/RECORD,,

limber_timber-0.0.1.dist-info/WHEEL

@@ -0,0 +1,4 @@
+Wheel-Version: 1.0
+Generator: poetry-core 2.1.2
+Root-Is-Purelib: true
+Tag: py3-none-any

limber_timber-0.0.1.dist-info/entry_points.txt

@@ -0,0 +1,3 @@
+[console_scripts]
+liti=liti.cli:main
+

liti/cli.py

@@ -0,0 +1,158 @@
+import logging
+from argparse import ArgumentParser, BooleanOptionalAction, Namespace
+
+from google.cloud import bigquery
+from pydantic import BaseModel, ConfigDict
+
+from liti.core.backend.base import DbBackend, MetaBackend
+from liti.core.backend.bigquery import BigQueryDbBackend, BigQueryMetaBackend
+from liti.core.backend.memory import MemoryDbBackend, MemoryMetaBackend
+from liti.core.client.bigquery import BqClient
+from liti.core.model.v1.schema import DatabaseName, Identifier, SchemaName, TableName
+from liti.core.runner import MigrateRunner, ScanRunner
+
+
+class Clients(BaseModel):
+    """ Used to ensure we have a single instance of any client that is needed
+
+    This becomes useful for example when it comes to having transactions that span the DB and metadata.
+    """
+    model_config = ConfigDict(arbitrary_types_allowed=True)
+
+    big_query: BqClient | None = None
+
+
+def parse_all_arguments() -> Namespace:
+    parser = ArgumentParser(prog='liti')
+    parser.add_argument('command', help='action to perform')
+    parser.add_argument('-t', '--target', help='directory with migration files')
+    parser.add_argument('-w', '--wet', action=BooleanOptionalAction, default=False, help='[False] should perform migration side effects')
+    parser.add_argument('-d', '--down', action=BooleanOptionalAction, default=False, help='[False] should allow performing down migrations')
+    parser.add_argument('-v', '--verbose', action=BooleanOptionalAction, default=False, help='[False] should log in a wet run')
+    parser.add_argument('--db', default='memory', help='[memory] type of database backend (e.g. memory, bigquery)')
+    parser.add_argument('--meta', default='memory', help='[memory] type of metadata backend (e.g. memory, bigquery)')
+    parser.add_argument('--meta-table-name', help='fully qualified table name for a metadata table')
+    parser.add_argument('--scan-database', help='database to scan')
+    parser.add_argument('--scan-schema', help='schema to scan')
+    parser.add_argument('--scan-table', help='table to scan')
+    parser.add_argument('--gcp-project', help='project to use for GCP backends')
+    return parser.parse_args()
+
+
+def parse_migrate_arguments() -> Namespace:
+    parser = ArgumentParser(prog='liti')
+    parser.add_argument('command', help='action to perform')
+    parser.add_argument('-t', '--target', required=True, help='directory with migration files')
+    parser.add_argument('-w', '--wet', action=BooleanOptionalAction, default=False, help='[False] should perform migration side effects')
+    parser.add_argument('-d', '--down', action=BooleanOptionalAction, default=False, help='[False] should allow performing down migrations')
+    parser.add_argument('-v', '--verbose', action=BooleanOptionalAction, default=False, help='[False] should log in a wet run')
+    parser.add_argument('--db', default='memory', help='[memory] type of database backend (e.g. memory, bigquery)')
+    parser.add_argument('--meta', default='memory', help='[memory] type of metadata backend (e.g. memory, bigquery)')
+    parser.add_argument('--meta-table-name', help='fully qualified table name for a metadata table')
+    parser.add_argument('--gcp-project', help='project to use for GCP backends')
+    return parser.parse_args()
+
+
+def parse_scan_arguments() -> Namespace:
+    parser = ArgumentParser(prog='liti')
+    parser.add_argument('command', help='action to perform')
+    parser.add_argument('--db', required=True, help='type of database backend (e.g. bigquery)')
+    parser.add_argument('--scan-database', required=True, help='database to scan')
+    parser.add_argument('--scan-schema', required=True, help='schema to scan')
+    parser.add_argument('--scan-table', help='table to scan, scan whole schema if not provided')
+    parser.add_argument('--gcp-project', help='project to use for GCP backends')
+    return parser.parse_args()
+
+
+def build_clients(args: Namespace) -> Clients:
+    client_ids = []
+
+    if 'db' in args:
+        client_ids.append(args.db)
+
+    if 'meta' in args:
+        client_ids.append(args.meta)
+
+    if 'bigquery' in client_ids:
+        if 'gcp_project' in args:
+            gcp_project = args.gcp_project
+        elif 'scan_database' in args:
+            gcp_project = args.scan_database
+        else:
+            raise ValueError('Unable to determine the GCP project to use for the client')
+
+        big_query_client = BqClient(bigquery.Client(project=gcp_project))
+    else:
+        big_query_client = None
+
+    return Clients(
+        big_query=big_query_client,
+    )
+
+
+def build_db_backend(args: Namespace, clients: Clients) -> DbBackend:
+    if args.db == 'memory':
+        return MemoryDbBackend()
+    elif args.db == 'memory':
+        return BigQueryDbBackend(clients.big_query)
+    else:
+        raise ValueError(f'Invalid database backend: {args.db}')
+
+
+def build_meta_backend(args: Namespace, clients: Clients) -> MetaBackend:
+    if args.db == 'memory':
+        return MemoryMetaBackend()
+    elif args.db == 'memory':
+        return BigQueryMetaBackend(clients.big_query, TableName(args.meta_table_name))
+    else:
+        raise ValueError(f'Invalid metadata backend: {args.db}')
+
+
+def migrate():
+    args = parse_migrate_arguments()
+    silent = args.wet and not args.verbose
+
+    if silent:
+        logging.basicConfig(level=logging.ERROR)
+    else:
+        logging.basicConfig(level=logging.INFO)
+
+    clients = build_clients(args)
+    db_backend = build_db_backend(args, clients)
+    meta_backend = build_meta_backend(args, clients)
+
+    runner = MigrateRunner(
+        db_backend=db_backend,
+        meta_backend=meta_backend,
+        target=args.target,
+    )
+
+    runner.run(
+        wet_run=args.wet,
+        allow_down=args.down,
+        silent=silent,
+    )
+
+
+def scan():
+    args = parse_scan_arguments()
+    clients = build_clients(args)
+    db_backend = build_db_backend(args, clients)
+    runner = ScanRunner(db_backend)
+
+    runner.run(
+        database=DatabaseName(args.scan_database),
+        schema=SchemaName(args.scan_schema),
+        table=Identifier(args.scan_table) if args.scan_table else None,
+    )
+
+
+def main():
+    args = parse_all_arguments()
+
+    if args.command == 'migrate':
+        migrate()
+    elif args.command == 'scan':
+        scan()
+    else:
+        raise ValueError(f'Invalid command: {args.command}')

liti/core/backend/__init__.py

@@ -0,0 +1 @@
+# TODO: support more backends

liti/core/backend/base.py

@@ -0,0 +1,125 @@
+from abc import ABC, abstractmethod
+
+from liti.core.base import Defaulter, Validator
+from liti.core.model.v1.operation.data.base import Operation
+from liti.core.model.v1.operation.data.table import CreateTable
+from liti.core.model.v1.schema import Column, ColumnName, DatabaseName, Identifier, RoundingModeLiteral, \
+    SchemaName, Table, \
+    TableName
+
+
+class DbBackend(ABC, Defaulter, Validator):
+    """ DB backends make changes to and read the state of the database """
+
+    @abstractmethod
+    def scan_schema(self, database: DatabaseName, schema: SchemaName) -> list[Operation]:
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def scan_table(self, name: TableName) -> CreateTable | None:
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def has_table(self, name: TableName) -> bool:
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def get_table(self, name: TableName) -> Table | None:
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def create_table(self, table: Table):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def drop_table(self, name: TableName):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def rename_table(self, from_name: TableName, to_name: Identifier):
+        raise NotImplementedError('not supported')
+
+    def set_clustering(self, table_name: TableName, columns: list[ColumnName] | None):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def set_description(self, table_name: TableName, description: str | None):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def set_labels(self, table_name: TableName, labels: dict[str, str] | None):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def set_tags(self, table_name: TableName, tags: dict[str, str] | None):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def set_default_rounding_mode(self, table_name: TableName, rounding_mode: RoundingModeLiteral):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def add_column(self, table_name: TableName, column: Column):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def drop_column(self, table_name: TableName, column_name: ColumnName):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def rename_column(self, table_name: TableName, from_name: ColumnName, to_name: ColumnName):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def set_column_nullable(self, table_name: TableName, column_name: ColumnName, nullable: bool):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def set_column_description(self, table_name: TableName, column_name: ColumnName, description: str | None):
+        raise NotImplementedError('not supported')
+
+    @abstractmethod
+    def set_column_rounding_mode(self, table_name: TableName, column_name: ColumnName, rounding_mode: RoundingModeLiteral):
+        raise NotImplementedError('not supported')
+
+
+class MetaBackend(ABC):
+    """ Meta backends manage the state of what migrations have been applied """
+
+    def initialize(self):
+        pass
+
+    @abstractmethod
+    def get_applied_operations(self) -> list[Operation]:
+        pass
+
+    @abstractmethod
+    def apply_operation(self, operation: Operation):
+        """ Add the operation to the metadata """
+        pass
+
+    @abstractmethod
+    def unapply_operation(self, operation: Operation):
+        """ Remove the operation from the metadata
+
+        The operation must be the most recent one.
+        """
+        pass
+
+    def get_previous_operations(self) -> list[Operation]:
+        return self.get_applied_operations()[:-1]
+
+    def get_migration_plan(self, target: list[Operation]) -> dict[str, list[Operation]]:
+        applied = self.get_applied_operations()
+        common_operations = 0
+
+        for applied_op, target_op in zip(applied, target):
+            if applied_op == target_op:
+                common_operations += 1
+            else:
+                break
+
+        return {
+            'down': list(reversed(applied[common_operations:])),
+            'up': target[common_operations:],
+        }