-
|
Hello everyone, I'm currently exploring the best approach to share a single database class across multiple packages within a monorepo. My goal is to manage the logic (DAOs, use cases, etc.) separately within each package. However, I've encountered a challenge: when I define the database in one package, I'm unable to access tables from the other packages. I'm utilizing Drift and Melos to manage multiple Flutter packages and apps within this setup. The primary objective is to evaluate the possibility of modularization of the logic in each package, aligning it with specific business functionalities. For instance, creating distinct Flutter packages/apps for login/authentication another one for users activities (completed activities, to-be assigned, etc). |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
If you need multiple parts of the database to be defined in different packages and then have multiple apps using different database components, I suggest using modular code generation. By default, drift only generates code next to database classes but you can make it generate code across a range of input files (e.g. next to table-defining sources and so on). You'll have to make minor adjustments in your imports after enabling modular code generation since the generated code then lives in different files, but it should enable modular setups across packages. |
Beta Was this translation helpful? Give feedback.
If you need multiple parts of the database to be defined in different packages and then have multiple apps using different database components, I suggest using modular code generation. By default, drift only generates code next to database classes but you can make it generate code across a range of input files (e.g. next to table-defining sources and so on).
You'll have to make minor adjustments in your imports after enabling modular code generation since the generated code then lives in different files, but it should enable modular setups across packages.