Moor: Generating table part files separate from database part?

[atcaines]

Since all tables are included in the database .part file, I need to import my database file any time I want to use any of my database's DataClasses.

Is there an existing way that I could generate my files but import model1.dart, model2.dart while restricting database operations to a select few files (repository) by importing the database.dart file there?

Alternatively, can I define my Table separate from the DataClass associated with the Tables so that I could import the DataClass without getting the companion, table, database etc?

I have it working in the meantime by manually splitting out the generated file into database.g.dart and model.g.dart after each generation but that is somewhat annoying.

[simolus3]

I see what you mean, but at the moment this is not possible. I think it's a valid request, but it won't be easy to implement. Moor also generates additional (private) classes in the part file to represent the table structure. These private classes have to be in a part file of the database file of course. This means that we'd have to split code generation over multiple files. I haven't found a good approach for this yet.

[atcaines]

Thanks for the info

In the meantime I wrote a python script that uses RegEx to extract each (Model, ModelCompanion) class pair to another file called model.g.dart starting with "part of '{model}.dart';". Then all that is left are the Table and Database classes in the original file.

Not ideal obviously since I'm relying on layout to extract them with RegEx but it does the job for now.

[simolus3]

We could have another set of builders generating files like this:

• each moor file and every Dart file declaring tables gets
  
  
  
  • a (build_to: cache) moor.json file containing entities (tables, triggers, indices) in a serialized form
  
  
  • a (visible) .moor.dart file containing all the generated classes
  
  
• instead of generating part files for databases, we'd generate regular files importing other files as necessary.

This scales much better to large projects, but a downside is that we'd generate a large amount of source files cluttering up the project. It'll also require another package to maintain. I have other priorities at the moment, but I think I can come up with a solution for this.

[ziakhan110]

any new on this?

[cervonwong]

This will be a great improvement for dependency inversion and managing dependencies between classes! :)