I have 3 separate migration in my app: 20241114121339_users, 20241118133344_books.rb, 20241122114836_apps.rb
I decided to create separate slice for api and put migration into
slices/api/config/db/migrate/20241128111648_create_admin_users.rb
Then I run the command:
bundle exec hanami db migrate
I got:
WARNING: Database myapp_test is configured for multiple config/db/ directories:
- config/db
- slices/admin_api/config/db
Using config in "my_app" slice only.
=> database my_app_test migrated in 0.0007s
WARNING: Database my_app_test is configured for multiple config/db/ directories:
- config/db
- slices/admin_api/config/db
Using config in "my_app" slice only.
=> my_app structure dumped to config/db/structure.sql in 0.0579s
Ant it didn’t change config/db/structure.sql
then I tried to run:
bundle exec hanami db migrate --slice api
And I got error:
/usr/local/bundle/gems/sequel-5.86.0/lib/sequel/extensions/migration.rb:783:in `get_applied_migrations': Applied migration files not in file system: 20241114121339_create_users, 20241118133344_create_books.rb, 20241122114836_create_apps.rb (Sequel::Migrator::Error)
Am I right in presuming that you only have a single database (i.e. a single DATABASE_URL) for your app?
Hanami’s database layer is designed for each distinct database to have its config (e.g. migrations) reside in a single slice only. By trying to add a new migration file to a slice when the rest of your config is elsewhere, you split the config across two places. This is why you receive the warning message.
If you’re sharing a single database across multiple slices, you should keep the config all together. In this case, I recommend you keep everything in config/db/ like you started with.
Yes. I only use one database
I would like to separate migration on slices to separate logic. Maybe it makes sense to introduce additional option to run migration in certain slice:)
In this case, you’ll need to keep all your database config (such as migrations) in a single config/db/ location only.
This is an intentional design choice. A single database is a single thing. We want to keep all related config also in a single place. This helps ensure that (a) the user understands what is going on, and (b) our code reliably and consistently operates on that database. If config is spread around then it becomes a recipe for user-confusion and inconsistently managed databases.
To expand on that: Hanami supports Slices having their own, independent DB configuration. In that case, you would have configuration in the Slice directory.
In order to reduce the boilerplate of configuring your persistence, the presence of a config/db directory tells the DB provider to enable itself for that context.
If Hanami were to support multiple locations for migrations, this would mean requiring more boilerplate configuration for all apps, and the location would no longer communicate the context in which it is being used.