Moor: Dao class can't live in seperate file from Database class

[KaungZawHtet]

This works because both classes are in the same file:

class AppDatabase extends _$AppDatabase { }

@UseDao(tables: [Users])
class UsersDao extends DatabaseAccessor<AppDatabase> with _$UsersDaoMixin 
  final AppDatabase db;
  // Called by the AppDatabase class
  UsersDao(this.db) : super(db);
}

And _$UsersDaoMixin shows error if UsersDao is at seperate code file

[simolus3]

Hm, that doesn't sound right, moor should have written the mixin into another file.
After you moved the dao in its own file (let's say it's called users_dao.dart), did you add a part "users_dao.g.dart"; directive in that new file? If so, please try to re-run the build runner with flutter packages pub run build_runner build. Moor should then write that _$UsersDaoMixin into a users_dao.g.dart file.

[KaungZawHtet]

After adding the line
part "users_dao.g.dart";

This is error
[SEVERE] moor_generator:moor_generator on lib/components/moor/moor_dao/users_dao.dart (cached): Error running DaoGenerator NoSuchMethodError: The getter 'listValue' was called on null. Receiver: null Tried calling: listValue [SEVERE] Failed after 123ms pub finished with exit code 1

This is code of users_dao.dart
```
import 'package:myapp/components/moor/moor_create/moor_create_Users.dart';
import 'package:myapp/components/moor/moor_database.dart';
import 'package:moor/moor.dart';
import 'package:moor_flutter/moor_flutter.dart';
part 'users_dao.g.dart';

@UseDao(tables: [Users])
class UsersDao extends DatabaseAccessor with _$UsersDaoMixin {
final AppDatabase db;
UsersDao(this.db) : super(db);
}
````

[simolus3]

Looks like a bug in moor. Can you give me the full stacktrace (run with flutter packages pub run build_runner build -v)?

[KaungZawHtet]

`
```

0 throwToolExit (package:flutter_tools/src/base/common.dart:28:3)

1 pubInteractively (package:flutter_tools/src/dart/pub.dart:190:5)

2 PackagesPassthroughCommand.runCommand (package:flutter_tools/src/commands/packages.dart:223:11)

3 FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:478:18)

4 FlutterCommand.run. (package:flutter_tools/src/runner/flutter_command.dart:383:33)

5 AppContext.run. (package:flutter_tools/src/base/context.dart:153:29)

6 _rootRun (dart:async/zone.dart:1124:13)

7 _CustomZone.run (dart:async/zone.dart:1021:19)

8 _runZoned (dart:async/zone.dart:1516:10)

9 runZoned (dart:async/zone.dart:1463:12)

10 AppContext.run (package:flutter_tools/src/base/context.dart:152:18)

11 FlutterCommand.run (package:flutter_tools/src/runner/flutter_command.dart:375:20)

12 CommandRunner.runCommand (package:args/command_runner.dart:197:27)

13 FlutterCommandRunner.runCommand.

(package:flutter_tools/src/runner/flutter_command_runner.dart:396:21)

14 AppContext.run. (package:flutter_tools/src/base/context.dart:153:29)

15 _rootRun (dart:async/zone.dart:1124:13)

16 _CustomZone.run (dart:async/zone.dart:1021:19)

17 _runZoned (dart:async/zone.dart:1516:10)

18 runZoned (dart:async/zone.dart:1463:12)

19 AppContext.run (package:flutter_tools/src/base/context.dart:152:18)

20 FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:356:19)

21 CommandRunner.run. (package:args/command_runner.dart:112:25)

22 new Future.sync (dart:async/future.dart:224:31)

23 CommandRunner.run (package:args/command_runner.dart:112:14)

24 FlutterCommandRunner.run (package:flutter_tools/src/runner/flutter_command_runner.dart:242:18)

25 run.. (package:flutter_tools/runner.dart:62:22)

26 _rootRun (dart:async/zone.dart:1124:13)

27 _CustomZone.run (dart:async/zone.dart:1021:19)

28 _runZoned (dart:async/zone.dart:1516:10)

29 runZoned (dart:async/zone.dart:1500:12)

30 run. (package:flutter_tools/runner.dart:60:18)

31 AppContext.run. (package:flutter_tools/src/base/context.dart:153:29)

32 _rootRun (dart:async/zone.dart:1124:13)

33 _CustomZone.run (dart:async/zone.dart:1021:19)

34 _runZoned (dart:async/zone.dart:1516:10)

35 runZoned (dart:async/zone.dart:1463:12)

36 AppContext.run (package:flutter_tools/src/base/context.dart:152:18)

37 runInContext (package:flutter_tools/src/context_runner.dart:56:24)

38 run (package:flutter_tools/runner.dart:51:10)

39 main (package:flutter_tools/executable.dart:62:9)

40 main (file:///Users/kaungzawhtet/flutter%20sdk/packages/flutter_tools/bin/flutter_tools.dart:8:3)

41 _startIsolate. (dart:isolate-patch/isolate_patch.dart:299:32)

42 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:12)

````

[simolus3]

Sorry, it looks like Flutter appends its own stacktrace when the build fails, there should have been another exception in the logs containing trace entries from package:moor_generator.

That said, I think the error can only occur when the annotation isn't constant for some reason. Just to be sure, you are importing the file that contains the Users class, right? I just tried to reproduce your problem in this gist https://gist.github.com/simolus3/4ebece3fe0307370564163e0b3abcff8 but that's working for me, even if I put the Users class into its own file and import it from database.dart and dao.dart.

[KaungZawHtet]

After creating your dao.dart in the same directory of database.dart, dao.g.dart was generated. And I re-created my users_dao.dart and now, my users_dao.g.dart is being generated and working meaninglessly now. Looks generator has unknown bug. Anyway, thx for ur help. This issue can be closed now

[sainoba]

Just for reference. I had a pretty similar issue. I "fixed" it by actually doing the circular import.
That's importing database.dart from dao.dart and vice-versa.

Silly mistake but I hope it helps people that find this issue.

[fgblomqvist]

@simolus3 Could you confirm that the correct way to achieve this is to use a circular import? Seems to be the only way (DB imports model and DAO, DAO imports Model and DB). Not a Dart expert but it seems odd to have a circular import (but it seems to work?).

[simolus3]

I don't see why the db would have to import the dao. I'm also not sure what you mean with "model". If you mean the generated table classes, those aren't really an import.
It's true that the dao has to import the main database file (which includes the generated tables), but apart from that I don't see a transitive import here.

[fgblomqvist]

If the DB doesn't import the DAO I can't specify the list of DAOs in UseMoor:

@UseMoor(tables: [Foos], daos: [FooDao])
class AppDatabase extends _$AppDatabase

Isn't that correct?
And as you can see, the list of tables contains the Foos class that I have declared in a separate file (and I call them models, since that's essentially what they are imo).

[simolus3]

Good point, I overlooked that. (Technically you can omit the daos in @UseMoor and it will still mostly work)

In this case a circular import between dao and db is necessary indeed. So far I didn't run into any issues with that. If you don't want to use them you could remove the daos section from the annotation. You can still use MyDao(myDatabase) manually to obtain a dao instance.

[fgblomqvist]

Ah okay, yeah I think I'll just go with MyDao(myDatabase) then to have a tad more peace-of-mind :)
Thanks!

[ChinaShrimp]

Based on this thread and this one: https://github.com/simolus3/moor/issues/241, we can seperate model(table)/database/dao into seperate folders, which model is the base, database depends on model, and dao depends on both.