Simplify template component handling to use migrations instead of schema placement#4932
Conversation
Replace the complex SQL merge/parse/placement logic with a simple migration component type. Templates now use "migration" components that copy SQL files to the migrations directory with a timestamp prefix. This removes ~1000 lines of SQL AST parsing, statement merging, and schema placement code. https://claude.ai/code/session_0161GS2RCbLFW2XqrwtjRYfp
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
This PR refactors the template component system to simplify SQL handling by removing the complex schema placement logic and consolidating all SQL components into a single "migration" component type. This eliminates hundreds of lines of SQL parsing and merging code while providing a clearer, more predictable behavior for template authors.
Key Changes
Removed SQL merging logic: Deleted ~750 lines of complex SQL statement parsing, merging, and deduplication code that attempted to intelligently merge ALTER statements into CREATE statements. This logic was error-prone and difficult to maintain.
Unified component types: Replaced multiple schema-based component types (
tables,functions,triggers,policies,extensions, etc.) with a single explicitmigrationcomponent type. Unknown component types now return an error instead of falling back to SQL handling.Simplified migration file creation: Migration files are now created directly in the migrations directory with timestamp-based naming (
YYYYMMDDHHMMSS_name.sql) rather than being distributed across schema directories based on component type and schema placement configuration.Removed schema placement configuration: Eliminated the
schema_placementconfiguration system and related code that allowed customizing where different SQL component types were stored. All migrations now go to a single migrations directory.Removed schema_paths configuration: Deleted the logic that automatically added
schema_pathsto the config when SQL components were added. Migrations are now the primary way to manage database schema changes.Deterministic migration timestamps: Added a
migrationTimestampfunction that accepts a sequence counter to ensure unique timestamps when multiple migrations are added in a single operation, preventing filename collisions.Implementation Details
The
executeMigrationComponentfunction replaces the previousexecuteSQLComponentfunction with a much simpler implementation that directly writes SQL content to a timestamped migration file.Removed dependencies on
multigresparser and custom SQL parsing utilities that were used for statement analysis.Updated tests to reflect the new behavior: migrations are created with timestamp prefixes in the migrations directory, and unsupported component types now properly return errors instead of silently falling back to SQL handling.
The
runtimeStatestruct now tracksmigrationSeq(sequence counter) instead ofaddedSql(list of added files).https://claude.ai/code/session_0161GS2RCbLFW2XqrwtjRYfp