-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infer migrations_paths from database name #36886
base: main
Are you sure you want to change the base?
Conversation
3d1860f
to
64a54a4
Compare
f83df6e
to
053a3f2
Compare
766f6a0
to
5c07af4
Compare
99ad51f
to
019d07f
Compare
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
c86ea82
to
9bb95bb
Compare
7a89e79
to
5c67db5
Compare
Similar to what we do for schema files, we now infer the default `migrations_paths` for a database configuration using the database specification name. We still allow overriding these defaults with a `migrations_paths` key in the database configuration file. Additionally, update some documentation accordingly in the guides. We've also removed `Migrator.migrations_paths` since we should be taking the `migrations_paths` off of the config instead. Co-authored-by: eileencodes <eileencodes@gmail.com>
5c67db5
to
8e25fd8
Compare
So we don't forget again in the future: The problem we hit with this PR is that we don't know which entry is the default and therefore should get
|
This (or the lack of this) behavior just bit us. The docs indicate (as of 7.0.3.1) that option 3 above is followed
This phrasing (specifically: "will use the default Rails filenames") makes it seemingly reasonable to assume that the migration path would also be inferred as Weirdly enough some additional impact of migrations_paths defaulting that surprised us: If a non-primary database does not need migrations (and therefore theoretically need not have migrations_path config), then a bunch of db:* rake tasks start failing. To whit:
This is especially odd when running rake tasks scoped to the primary db. (Which seems to indicate that the "abort-if-pending-migrations" check is not scoped to the db whose tasks are being requested.) Example: defaults:
shared: &shared
adapter: mysql2
encoding: utf8mb4
username: root
password: pass
host: 127.0.0.1
port: 3306
the_main: &the_main_defaults
<<: *shared
the_second: &the_second_defaults
<<: *shared
use_metadata_table: false
development:
the_main:
<<: *the_main_defaults
database: main
the_second:
<<: *the_second_defaults
database: second
drops the_main development db and then promptly fails/exits with: "You have N pending migrations:" ( While it seems clear there are a handful of interrelated quirks with these db tasks; at least one prevention mechanism is for Some other strange behavior: |
Will It doesn't sound like the bugs you're discussing are directly related to this PR and unfortunately there are too many problems we hit to move forward at this time. If there are areas for improvement a new issue should be opened with a reproduction. |
Summary
Similar to what we do for schema files, we now infer the default
migrations_paths
for a database configuration using the databasespecification name.
We still allow overriding these defaults with a
migrations_paths
keyin the database configuration file.
Additionally, we've updated some documentation accordingly in the guides.
We've also removed
Migrator.migrations_paths
since we should be takingthe
migrations_paths
off of the config instead.cc / @eileencodes