Change8

data-table@0.2.0

Breaking Changes
📦 remixView on GitHub →
11 breaking7 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

  1. Replace usages of `AdapterStatement` with `DataManipulationOperation`.
  2. Replace usages of `statement` with `operation`.
  3. Update adapter execution calls to use `execute` for DML and `migrate` for DDL/migration requests.
  4. Replace usages of `QueryBuilder` API calls with `Query` objects created via `query(table)` and executed via `db.exec(...)`.
  5. Update terminal method calls (e.g., `.first()`) to expect a `Query` object return instead of a command descriptor type.
  6. Update imports: move `SqlStatement`, `sql`, and `rawSql` from `@remix-run/data-table/sql` to `@remix-run/data-table`.
  7. Rename `createTable(...)` to `table(...)` when defining schemas.
  8. Switch column definitions to use `column(...)` builders.
  9. Remove calls to `getTableValidationSchemas(...)` and rely on table-scoped validation via `validate(...)`.
  10. 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