data-table@0.2.0
Breaking Changes📦 remixView on GitHub →
⚠ 11 breaking✨ 7 features🔧 40 symbols
Summary
This release introduces significant breaking changes across the adapter API, query building, and schema definition, while adding a robust, first-class migration system with enhanced lifecycle callbacks.
⚠️ Breaking Changes
- Adapter operation contracts and fields were renamed: `AdapterStatement` is now `DataManipulationOperation`, and `statement` is now `operation`.
- Adapter execution methods are split: use `execute` for `DataManipulationOperation` requests and `migrate` for `DataMigrationOperation` requests.
- The public `QueryBuilder` API is replaced by `Query` objects created via `query(table)`. Execution now uses `db.exec(...)` which accepts raw SQL or `Query` values.
- Unbound terminal methods (`first()`, `count()`, `exists()`, `insert()`, `update()`, and `delete()`) now return `Query` objects instead of separate command descriptor types.
- The incidental `QueryMethod` type export is removed; use `Database['query']` or `QueryForTable<table>` for that type shape.
- The export `@remix-run/data-table/sql` is removed. Import `SqlStatement`, `sql`, and `rawSql` from `@remix-run/data-table` instead.
- The top-level table-definition helper is renamed from `createTable(...)` to `table(...)`, and column definitions now use `column(...)` builders.
- Runtime validation is now optional and table-scoped via `validate({ operation, tableName, value })`.
- Removed `~standard` table-schema compatibility and `getTableValidationSchemas(...)`.
- Stopped runtime validation/coercion for predicate values.
- The `@remix-run/data-table/migrations` export no longer provides a separate `Database` type alias; import `Database` from `@remix-run/data-table` if the type is needed directly.
Migration Steps
- Replace usages of `AdapterStatement` with `DataManipulationOperation`.
- Replace usages of `statement` with `operation`.
- Update adapter execution calls to use `execute` for DML and `migrate` for DDL/migration requests.
- Replace usages of `QueryBuilder` API calls with `Query` objects created via `query(table)` and executed via `db.exec(...)`.
- Update terminal method calls (e.g., `.first()`) to expect a `Query` object return instead of a command descriptor type.
- Update imports: move `SqlStatement`, `sql`, and `rawSql` from `@remix-run/data-table/sql` to `@remix-run/data-table`.
- Rename `createTable(...)` to `table(...)` when defining schemas.
- Switch column definitions to use `column(...)` builders.
- Remove calls to `getTableValidationSchemas(...)` and rely on table-scoped validation via `validate(...)`.
- Update migration callback contexts to use `{ db, schema }` handles.
✨ New Features
- Added adapter introspection methods with optional transaction context: `hasTable(table, transaction?)` and `hasColumn(table, column, transaction?)`.
- Added a first-class migration system under `remix/data-table/migrations` supporting `createMigration(...)`, timestamp-based loading, chainable schema APIs (create, alter, drop, index), and `createMigrationRunner`.
- Migration callbacks now use split handles: `{ db, schema }`, where `schema` handles migration operations like `createTable` and `alterTable`.
- Migration dry-run mode now allows schema introspection (`schema.hasTable` / `schema.hasColumn`) to read live database state.
- Added public subpath exports for migrations, Node migration loading, SQL helpers, operators, and SQL builders.
- Added optional table lifecycle callbacks: `beforeWrite`, `afterWrite`, `beforeDelete`, `afterDelete`, and `afterRead`.
- Added `fail(...)` as a helper for returning structured validation/lifecycle issues from `validate(...)`, `beforeWrite(...)`, and `beforeDelete(...)`.
Affected Symbols
AdapterStatementDataManipulationOperationstatementoperationexecutemigrateDataMigrationOperationhasTablehasColumnQueryBuilderQueryqueryexecfirst()count()exists()insert()update()delete()QueryMethodDatabase['query']QueryForTable<table>@remix-run/data-table/sqlSqlStatementsqlrawSql@remix-run/data-table/sql-helperscreateTabletablecolumnvalidategetTableValidationSchemasDatabasecreateDatabasebeforeWriteafterWritebeforeDeleteafterDeleteafterReadfail