Migrating from drift 1.x to drift 2.x
The first major upgrade from drift 1 to drift 2 involves a number of breaking changes and the removal of legacy features. These changes make drift easier to maintain and easier to use.
This overview describes important breaking changes and how to apply them to your project. For a full list of updates, see the changelog.
Null-safety only: Drift will always emit null-safe code now. To use drift 2.x, please migrate your application (or at least the parts defining the database) to Dart 2.12 or later.
Expressionalways have a non-nullable type parameter now. That is, use
Expression<int?>. The old distinction was an attempt to embed SQL's behavior around
NULLvalues into Dart's typesystem. This didn't work, and so expressions no longer have associated nullability in their types.
Reading nullable expressions:
QueryRow.read(used to read columns from a complex select in Dart) only supports non-nullable values now. To read nullable values, use
Updated type converters: The
mapToDartmethods have been renamed to simply
toDart, respectively. Also, a type converter only needs to support the exact types that it was declared with. In particular, a
TypeConverter<MyObject, String>no longer needs to deal with
nullvalues in either direction.
Type converters that are declared as nullable (e.g.
TypeConverter<Foo?, int?>) can no longer be applied to non-nullable columns. These changes bring proper null-safety support to type converters and make their behavior around null values more intuitive.
Changed builder options: To reduce the complexity of
drift_dev, and to make some long-recommended builder options the default, some options have been removed or had their defaults changed.
- The following options are no longer available:
new_sql_code_generation: Always enabled now. If this changes the behavior of your queries, please open an issue!
null_aware_type_converters: This is always enabled now with the new semantics for type converters.
compact_query_method: Has been enabled by default before, can no longer be disabled now.
eagerly_load_dart_ast: This option used to not do anything for a while and has been removed entirely now.
- In addition, the defaults for these options has changed (but the existing behavior can be restored if desired):
apply_converters_on_variablesis enabled by default now.
generate_values_in_copy_withis enabled by default now.
scoped_dart_componentsis enabled by default now.
- The generated
fromDatafactory on data classes is no longer generated. Use the
mapmethods on the table instance instead (e.g.
The breaking changes in drift 2.0 are motivated by making drift easier to maintain and to unblock upcoming new features. This release also provides some new features, like nested transactions or support for
RETURNING for updates and deletes in the Dart API. We hope the upgrade is worthwhile. If you run into any issues, please do not hesistate to start a new discussion or to open an issue. Thanks for using drift!
Moor has been renamed to
drift. The reason for this is that, in some parts of the world, moor may be used as a derogatory term. I have not been aware of this when starting this project, but we believe that the current name does not reflect the inclusivity of the Dart and Flutter communities. Despite the associated effort, I'm convinced that renaming the project is the right decision. Thank you for your understanding!
5.0.0, the current
moor_generator packages will continue to work - no urgent action is necessary. All features and fixes to the new
drift packages will be mirrored in
moor as well. With the release of drift 2.0.0, the
moor set of packages have been discontinued in favor of
This page describes how to migrate from the old
moor package to the new
drift package. This process can be automated, and we hope that the migration is a matter of minutes for you. In case of issues with the tool, this page also describes how to manually migrate to the new
To make the name change as easy as possible for you, drift comes with an automatic migration tool for your project. It will analyze your source files and perform all changes that come with this migration.
To use the migration tool, please first make sure that you're using
4.6.0 or later, for instance by updating your dependency on it:
dev_dependencies: moor_generator: ^4.6.0
Next, please make sure that your project does not contain analysis errors, as this could make the migration tool less effective. Also, please create a backup of your project's files before running the migration tool. It will override parts of your sources without further confirmation. When using git, it is sufficient to ensure that you have a clean state.
To apply the migration, run
dart run moor_generator migrate in your project's directory. When using Flutter, run
flutter pub run moor_generator migrate instead. The migration tool will transform your pubspec,
build.yaml files and Dart source files. It will also rename
.moor files to
.drift and patch imports as needed.
After running the migration, please verify the changes to ensure that they match what you expect. Also, you may have to
- Format your sources again: Run
dart format .or
flutter format .
- Re-run the build: Run
dart run build_runner buildor
flutter pub run build_runner build --delete-conflicting-outputs, respectively.
- Manually fix the changed order of imports caused by the migration.
Congratulations, your project is now using drift!
If you run into any issues with the automatic migration tool, please open an issue.
To migrate from
drift, you may have to update:
- Your pubspec
- Dart imports
- Dart code, to reflect new API names
build.yamlconfiguration files, if any
The following sections will describe each of the steps.
First, replace the
moor dependency with
dependencies: drift: ^2.1.0 dev_dependencies: drift_dev: ^2.1.0
If you've been using
moor_flutter, also add a dependency on
pub get to get the new packages.
Changing Dart imports
This table compares the old imports from
moor and the new imports for
|Moor import||Drift import|
Changing Dart code
This table compares old moor-specific API names and new names as provided by
|Moor name||Drift name|
(Optional: Rename moor files)
For consistency, you can rename your
.moor files to
.drift. The drift generator will continue to accept
.moor files though.
If you opt for a rename, also update your imports and
include: parameters in database and DAO classes.
When configuring moor builders for options, you have to update your
build.yaml files to reflect the new builder keys:
|Moor builder key||Drift builder key|