Goal
Extend clone-schema beyond table metadata so same-engine clones can optionally preserve advanced database objects used by mature schemas.
Current clone coverage focuses on tables, columns, exact column DDL types, nullability, defaults, stored generated columns, PKs, FKs, simple CHECK constraints, enum values, comments, and non-primary indexes. Advanced objects are intentionally out of scope today.
Proposed scope
Add cloning support for same-engine compatible advanced schema objects:
- Partial indexes
- Expression/function indexes
- Views
- Triggers
- Functions/procedures/routines
This should remain same-engine only. Do not attempt Postgres-to-MySQL or MySQL-to-Postgres translation.
Expected behavior
clone-schema should preserve advanced objects after base tables are created.
- Object creation should be dependency-aware:
- tables before indexes/views/triggers
- functions/routines before triggers or views that reference them
- views ordered by dependencies where possible
- Dry-run output should include these objects in execution order.
- Errors should identify the object type/name and statement that failed.
- Objects should be cloned only for the active/default schema scope seedstorm supports today.
- If an object cannot be safely represented, clone should fail with a clear message or skip only under an explicit future opt-in flag.
Design notes
Recommended implementation order:
- Partial and expression indexes
- Views
- Triggers
- Functions/procedures/routines
This keeps risk controlled because routines/triggers can execute behavior and may depend on security, language, delimiter, or version details.
Edge cases to test
Postgres
- Partial index:
CREATE INDEX ... WHERE deleted_at IS NULL
- Expression index:
CREATE INDEX ... ON users (lower(email))
- Unique expression index
- View depending on one table
- View depending on another view
- Function used by a view or generated expression
- Trigger function plus trigger on insert/update
- Trigger and function with quoted identifiers and string literals
- Objects with comments where supported
- Existing target with
--drop-existing removes/replaces dependent objects cleanly
- Dry-run includes objects in dependency-safe order
- Unsupported/invalid routine language produces a clear failure
MySQL
- Functional index on MySQL 8.0+ if supported by the matrix version
- Generated-column-backed index as compatibility fallback if needed
- View depending on one table
- View depending on another view
- Trigger body with semicolons/delimiter-sensitive SQL
- Stored procedure/function with deterministic attributes
- Routine/trigger references quoted identifiers and string literals
- MySQL 5.7 behavior is explicitly handled or skipped with a clear reason when unsupported
- Dry-run emits executable statements without client-only delimiter syntax when using
database/sql
Cross-cutting regression tests
- Cloned schema can be introspected after advanced objects are created.
- Clone can run against an empty target and with
--drop-existing.
- Clone fails cleanly for cross-engine source/target.
- Advanced object clone should not break basic table clone behavior.
- CI matrix should cover all configured Postgres/MySQL versions where feature support exists.
Non-goals
- Cross-engine translation
- Grants/ownership/roles
- Extensions installation
- Non-default schemas until seedstorm supports explicit schema selection
- Data migration
Goal
Extend
clone-schemabeyond table metadata so same-engine clones can optionally preserve advanced database objects used by mature schemas.Current clone coverage focuses on tables, columns, exact column DDL types, nullability, defaults, stored generated columns, PKs, FKs, simple CHECK constraints, enum values, comments, and non-primary indexes. Advanced objects are intentionally out of scope today.
Proposed scope
Add cloning support for same-engine compatible advanced schema objects:
This should remain same-engine only. Do not attempt Postgres-to-MySQL or MySQL-to-Postgres translation.
Expected behavior
clone-schemashould preserve advanced objects after base tables are created.Design notes
Recommended implementation order:
This keeps risk controlled because routines/triggers can execute behavior and may depend on security, language, delimiter, or version details.
Edge cases to test
Postgres
CREATE INDEX ... WHERE deleted_at IS NULLCREATE INDEX ... ON users (lower(email))--drop-existingremoves/replaces dependent objects cleanlyMySQL
database/sqlCross-cutting regression tests
--drop-existing.Non-goals