Moor: Support for null safety

[noordawod]

Hi, and thanks for the plugin!

I'm having trouble using the null-safe version of sqflite as Moor is still dependent on the previous iteration of the said plugin.

Trying to use sqflite 2.0.0-nullsafety.2 produces:

$ flutter pub get
Running "flutter pub get" in example_app...

Because example_app depends on moor_flutter 3.1.0 which depends on sqflite ^1.1.6+5, sqflite ^1.1.6+5 is required.
So, because example_app depends on sqflite 2.0.0-nullsafety.2, version solving failed.
pub get failed (1; So, because example_app depends on sqflite 2.0.0-nullsafety.2, version solving failed.)
Process finished with exit code 1

Any plans to migrate to a null-safe Dart?

PS: null safety will be the default beyond 2020.

[simolus3]

I already started to migrate the moor packages, but I didn't want to publish them because I might want to introduce additional breaking changes.
I can release the null-safe versions to a personal pub server, that makes them a bit easier to use than with a git dependency override.

[simolus3]

I uploaded the current version of these packages to my pub server, you can use them like this:

dependencies:
  moor:
    hosted:
      url: https://simonbinder.eu
      name: moor
    version: ^4.0.0-nullsafety
  moor_flutter:
    hosted:
      url: https://simonbinder.eu
      name: moor_flutter
    version: ^4.0.0-nullsafety

dev_dependencies:
  moor_generator:
    hosted:
      url: https://simonbinder.eu
      name: moor_generator
    version: ^4.0.0-dev

I'll keep this issue open until these packages are on the real pub.

[davidmartos96]

@simolus3 Is there any opened issue tracking your thoughts on possible breaking changes with NNBD?

[simolus3]

I've opened #965 to list them. I might run into more things that deserve a breaking change, in that case I'll comment on that issue.

[noordawod]

Thanks guys, I will patiently then for the pub version.

[12people]

@simolus3 The hosted version is incompatible with path_provider 1.6.24. There is no newer version on pubdev. What can I do to get my app to run?

[simolus3]

Which moor version are you using? ^4.0.0-nullsafety? Can you post the explanation pub gives when using that with path_provider? You might have to add some dependency overrides.

[12people]

Yes, 4.0.0-nullsafety, as per the YAML above.

Here's what I get when I try to compile:

Because no versions of path_provider match >1.6.24 <2.0.0 and path_provider 1.6.24 depends on path_provider_windows ^0.0.4, path_provider ^1.6.24 requires path_provider_windows ^0.0.4.

And because every version of path_provider_windows depends on ffi ^0.1.3 and sqlite3 >=0.1.9-nullsafety.0 depends on ffi ^0.2.0-nullsafety, path_provider ^1.6.24 is incompatible with sqlite3 >=0.1.9-nullsafety.0.

Because every version of moor depends on sqlite3 ^0.1.9-nullsafety and no versions of sqlite3 match >=0.1.9-nullsafety <0.1.9-nullsafety.0, every version of moor requires sqlite3 ^0.1.9-nullsafety.0.
Thus, path_provider ^1.6.24 is incompatible with moor.

So, because app depends on both moor ^4.0.0-nullsafety and path_provider ^1.6.24, version solving failed.

These are my dependencies:

dependencies:
  flutter:
    sdk: flutter
  moor:
    hosted:
      url: https://simonbinder.eu
      name: moor
    version: ^4.0.0-nullsafety
  sqlite3_flutter_libs: ^0.3.0
  path_provider: ^1.6.24
  path: ^1.7.0

dev_dependencies:
  moor_generator:
    hosted:
      url: https://simonbinder.eu
      name: moor_generator
    version: ^4.0.0-dev
  build_runner: ^1.10.11

[simolus3]

It should work if you add this to your pubspec:

dependency_overrides:
  ffi: ^0.2.0-nullsafety

Unfortunately, you'll likely need overrides like that until all your dependencies are migrated.

[12people]

Wonderful, thanks!

[kuhnroyal]

I can't build 2 projects anymore with the 4.0.0-nullsafety.1 version. Tried everything I could think of but there is just an endless log of InconsistentAnalysisException for moor files and afterwards even more AssetNotFoundException for dart_in_moor files.

Also this old friend has reappeared after it was gone for a while:

NoSuchMethodError: The getter 'resolvedImports' was called on null.
Receiver: null
Tried calling: resolvedImports

[simolus3]

Oh no :scream: Can you post the stack trace for the InconsistentAnalysisException? I'm pretty sure that the AssetNotFoundException is directly caused by that (I slightly improved the UX in 43f90b6a43d8932dcc3867f20d79fe37a174a313, but we can't read type converters in moor files without the first step).

[kuhnroyal]

I don't get any stacks by default. It is also random on which files it fails.
There are 50+ tables and almost all use a generic type converter or enums.
I cherry-picked your analyzer workaround into develop and tried that but it didn't work.
Will try your latest commit and see what I get.

[kuhnroyal]

The new output is great! It is definitely related to converters, endless lines like this:

[INFO] moor_generator:moor_generator_not_shared on lib/db/foo_database.dart:line 53, column 51: Generated helper file not found. Check the build log for earlier errors.
   ╷
53 │     foo_type               INTEGER MAPPED BY `const BuiltValueEnumConverter<FooTypeEnum>()`,
   │                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But the inconsistencies are not really logged:

[SEVERE] moor_generator:preparing_builder on lib/db/foo/baz.moor:

InconsistentAnalysisException: Requested result might be inconsistent with previously returned results

[SEVERE] moor_generator:preparing_builder on lib/db/foo/foo.moor:

InconsistentAnalysisException: Requested result might be inconsistent with previously returned results

[SEVERE] moor_generator:preparing_builder on lib/db/foo/bar/bar.moor:

[kuhnroyal]

I tried all kinds of imports, relative, absolute etc. but I am quite sure they are all correct.
This is also a long list and it is still random which of the tables fail.

[simolus3]

I found something that looks suspicious - can you try using the generator from 4575287ba4ee11a950031cd6f594631b9705639f?

[kuhnroyal]

This worked, awesome! 🍾

[kuhnroyal]

So the generator now always works, that is great. :)
But it also always generates null safe code. From other generators I was under the impression that generators are supposed to output code depending on the language level of the project they are used in. e.g. by somehow looking at the dart constraint >=2.10 <3.0.0 or the dart file language level override // @dart=2.10.

"Supposed to" is probably the wrong wording - more like, in the spirit of compatibility they chose to do so.
There are still a lot of libraries missing nullsafety versions for my projects to go to Dart 2.12 but I need to keep up with all the other updates. It probably requires some work to get this in but I think it would be the best way.

[kuhnroyal]

From what I can see, they are using element.library.isNonNullableByDefault to figure this out.

[kuhnroyal]

Nvm, you did this already :) It just doesn't work for my converters, investigating...

[kuhnroyal]

@simolus3 I found no more issues after this, thanks for your quick help! Took me a while to figure out I had to use readTableOrNull for some results.

[simolus3]

Thanks! I changed the ArgumentError thrown to point out readTableOrNull in 4ffe29fe1768dbc6ee30c47fc85aea07b62b0263.

[kuhnroyal]

@simolus3 So due getSingle() etc. now being in an extension, they can no longer be mocked. Any ideas?

[kuhnroyal]

@simolus3 So due getSingle() etc. now being in an extension, they can no longer be mocked. Any ideas?

Ok, to answer my own question: The extensions obviously can not be mocked but they always call get/watch, those need to be mocked instead.

[simolus3]

I think I'll just revert that extension change, it caused plenty trouble for almost no value (as long as we don't override them, methods are effectively static too). Going the other way isn't nearly as breaking, so I think its justifiable for a 4.0.0-nullsafety.2 release.

Mocking get() should work though, as you found out too :D