[GH-ISSUE #840] about migration && schema.rs path #590

New issue

Closed

opened 2026-03-03 02:01:06 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 02:01:06 +03:00

Owner

Originally created by @insub on GitHub (Jan 31, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/840

Subject of the issue

I use sqlite db on development and mysql db on production.
If i run diesel migration generate <name> (like bitwarden_rs's wiki)
the migration file generate and put in "migrations/" , but not "migrations/sqlite",
so i have to run diesel migration generate <name> --migration-dir migrations/sqlite

The same happens when you execute build, the schema.rs generate and put in "src/db/", not "src/db/schemas/sqlite"

Your environment

MacOS 10.15.3

Bitwarden_rs version:
v1.13.1

Steps to reproduce

diesel migration generate <name>
cargo run --features sqlite

Expected behaviour

schema.rs put in "src/db/schemas/sqlite"

Actual behaviour

schema.rs put in "src/db"

Originally created by @insub on GitHub (Jan 31, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/840 ### Subject of the issue I use sqlite db on development and mysql db on production. If i run `diesel migration generate <name>` (like bitwarden_rs's wiki) the migration file generate and put in "migrations/" , but not "migrations/sqlite", so i have to run `diesel migration generate <name> --migration-dir migrations/sqlite` The same happens when you execute build, the schema.rs generate and put in "src/db/", not "src/db/schemas/sqlite" ### Your environment MacOS 10.15.3 * Bitwarden_rs version: v1.13.1 ### Steps to reproduce `diesel migration generate <name>` `cargo run --features sqlite` ### Expected behaviour schema.rs put in "src/db/schemas/sqlite" ### Actual behaviour schema.rs put in "src/db"

kerem closed this issue

2026-03-03 02:01:07 +03:00

kerem commented

2026-03-03 02:01:07 +03:00

Author

Owner

@dani-garcia commented on GitHub (Feb 4, 2020):

Yeah, it's one of the quirks of trying to work with a SQL library that isn't very focused in supporting multiple databases simultaneously, you'll have to handle the moving files to their respective folders and also generating those different schemas and migrations per database. I don't think there's much we can do about it

@dani-garcia commented on GitHub (Feb 4, 2020): Yeah, it's one of the quirks of trying to work with a SQL library that isn't very focused in supporting multiple databases simultaneously, you'll have to handle the moving files to their respective folders and also generating those different schemas and migrations per database. I don't think there's much we can do about it