Improving dx by separating the cargo loco db from src/ code

[CharlieBytesX]

First of all, thanks for making this framework, it's a dream come true for me...

Suggestion:
Suppose we need to make some changes to the database schema in the ./migration/src migration files. If we forget one of the changes and run cargo loco db reset, we are forced to fix all the app code in ./src/ just to be able to run cargo loco db reset again.

If the app code is not updated to match the current schema, we cannot make further changes to the schema.

It would be really helpful if the cargo loco db command—or any alternative approach you choose in the future—could run independently of the application's source code. This would allow schema changes without being blocked by mismatches in the app code.

[jondot]

thanks!
yes, there are plans for componentization, which is separating the db management part
ideally we want to keep a "one cli to rule them all" but be able to also have the experience you're indicating.
if you'd like to submit a draft PR for how this might work, i'll be happy to look at it

[CharlieBytesX]

Great!!
What recommendation do you give me to start exploring the current state of the cli and the db handling?

[jondot]

• CLI is here, it is laid out flat, and you can explore the DB parts and how it calls stuff in db.rs.
• An app "captures" a migrator by specifying it as a generic parameter, and so you'll see a lot of M:: calls. After compilation this will call the actual migrator from the migration crate
• While migrator can do "up" and "down" easily (it is part of the migration crate), there is also: truncate, seed, and reset, so need to take these into account as well (perhaps the migration crate needs to take a reference to Loco, and then provide the DB operations itself)
• To separate the two you can form 2 different strategies: (a) two separate crates, where one fails but the other can keep compiling. (b) two separate binaries, where one can still run if the other fails compiling. either way there should be some kind of "overwatching CLI" which is a single entry point to call both.

I feel there is a lot of experimentation in this kind of refactor, as there is no one definite good way to solve, so expect experimenting and throwing away experiments while reaching something that works

[CharlieBytesX]

Thanks!! Will check it out