Skip to content

Drift 2.15.0

Compare
Choose a tag to compare
@simolus3 simolus3 released this 17 Jan 23:01
· 635 commits to develop since this release
drift-2.15.0
38d603c

Drift 2.15 introduces new features improving web support and for sharing database classes against different databases (e.g. sqlite3 and Postgres):

  • Better support for custom SQL types:
    • Custom types are now applied consistently in the query builder API.
    • Add DialectAwareSqlType, a custom type depending on the runtime dialect. This allows writing "polyfill" types that use native date types on Postgres while falling back to a textual representation on sqlite3 for instance.
  • Initial JSONB support: sqlite 3.45 supports a binary JSON format aiming at reducing size and improving performance for JSON operations in SQL. Drift 2.15.0 supports jsonb functions in the query builder through package:drift/extensions/json1.dart. jsonb functions are also supported by sqlparser when analyzing drift files.
  • Runtime improvements:
    • Wasm databases hosted in workers are closed after the last client disconnects.
    • Add enableMigrations parameter to NativeDatabase to disable migrations, a flag useful for existing databases managed with an external schema tool.
  • Add analysis errors for illegal unqualified references to old and new in CREATE TRIGGER statements.

This release fixes a bug in the generator that is potentially breaking: Tables defined in .drift files with a NULL column constraint (e.g. CREATE TABLE users (display_name TEXT NULL, ...)) were not generated correctly - the NULL constraint was absent from the generated schema. This is not a soundness issue since NULL constraints are the default and ignored by sqlite3. However, it means that the actual schema of databases deviates from what drift will now expect, since NULL constraints will be expected from drift 2.15. This can cause issues with the schema validator after upgrading. If you are affected by this problem, the two possible ways to fix this are:

  1. To remove NULL constraints from column declarations in drift files. You don't need a migration for this since they don't affect semantics.
  2. To keep NULL constraints. In this case, you'll have to increment the schema version of your database and use Migrator.alterTable(affectedTable) on all affected tables to make it consistent with the schema with NULL constraints that drift is now expecting.

Also note that this only applies to drift files and not to NOT NULL constraints, which have always been generated correctly. Finally, older snapshots generated with drift_dev schema generate will continue to not report the NULL constraint, meaning that older migration tests won't break due to this change. If you have any questions or concerns about this, please reach out by opening an issue.