| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
It has been to use an overall rails command in ea4f0e2baba8653b03fba154357842933cf7b778, in order to unify.
|
|
|
|
| |
This reverts commit 11e85b91731ca6125ee1db33553f984549a3bc2b.
|
| |
|
|\
| |
| |
| |
| | |
schneems/schneems/migration-sets-environment-value
Set environment even when no migration runs
|
| |
| |
| |
| |
| | |
This PR addresses the issue described in https://github.com/rails/rails/pull/22967#issuecomment-170251635. If the database is non empty and has no new migrations than `db:migrate` will not set the environment. This PR works by always setting the environment value on successful `up` migration regardless of whether or not a migration was actually executed.
|
| | |
|
|/
|
|
|
|
|
|
| |
If for some reason some one is not able to set the environment from a migration this gives us an escape valve to manually set the environment for the database see https://github.com/rails/rails/pull/22967#issuecomment-170251635.
We will also fix the migration case, but this will ensure there is always a way to set the environment.
cc/ @sgrif
|
|\
| |
| | |
Prevent destructive action on production database
|
| | |
|
| | |
|
| |
| |
| |
| | |
Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035
|
| |
| |
| | |
Raise an error when a destructive action is made on a database where the current environment is different from the environment stored in the database.
|
| |
| |
| |
| |
| |
| |
| | |
This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd.
It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large.
To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.
|
| |
| |
| |
| | |
- So that we can just copy paste the command and execute it
|
|/
|
|
| |
Still more to do. Please assist!
|
|
|
|
|
| |
Even though this means more things to change when we bump after a
release, it's more important that our examples are directly copyable.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If we use a real version, at best that'll be an onerous update required
for each release; at worst, it will encourage users to write new
migrations against an older version than they're using.
The other option would be to leave these bare, without any version
specifier. But as that's just a variant spelling of "4.2", it would seem
to raise the same concerns as above.
|
| |
|
|
|
|
|
|
|
|
|
| |
- key was a poor choice of name. A key implies something that will
unlock a lock. The concept is actually more like a 'lock identifier'
- mysql documentation calls this a 'lock name'
- postgres documentation calls it a 'lock_id'
- Updated variable names to reflect the preferred terminology for the database in
question
|
|
|
|
|
|
|
|
|
|
| |
Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.
And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`1_valid_people_have_last_names.rb` and
`20150823202140_create_users.rb` are valid migration file name.
But `1_valid_people_have_last_names.rb` is rendered as
`********** NO FILE **********` when `rake db:migrate:status`.
Fix to this bug, this commit includes
* define some API private methdos and a Constant
`match_to_migration_filename?`, `parse_migration_filename`, and
`MigrationFilenameRegexp`
* use these methods in `db:migrate:status` task
Example:
These files are in `db/migrate`
* 1_valid_people_have_last_names.rb
* 20150819202140_irreversible_migration.rb
* 20150823202140_add_admin_flag_to_users.rb
* 20150823202141_migration_tests.rb
* 2_we_need_reminders.rb
* 3_innocent_jointable.rb
we can migrate all of them.
Before
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 ********** NO FILE **********
up 002 ********** NO FILE **********
up 003 ********** NO FILE **********
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
After
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 Valid people have last names
up 002 We need reminders
up 003 Innocent jointable
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Addresses issue #22092
- Works on Postgres and MySQL
- Uses advisory locks because of two important properties:
1. The can be obtained outside of the context of a transaction
2. They are automatically released when the session ends, so if a
migration process crashed for whatever reason the lock is not left
open perpetually
- Adds get_advisory_lock and release_advisory_lock methods to database
adapters
- Attempting to run a migration while another one is in process will
raise a ConcurrentMigrationError instead of attempting to run in
parallel with undefined behavior. This could be rescued and
the migration could exit cleanly instead. Perhaps as a configuration
option?
Technical Notes
==============
The Migrator uses generate_migrator_advisory_lock_key to build the key
for the lock. In order to be compatible across multiple adapters there
are some constraints on this key.
- Postgres limits us to 64 bit signed integers
- MySQL advisory locks are server-wide so we have to scope to the
database
- To fulfil these requirements we use a Migrator salt (a randomly
chosen signed integer with max length of 31 bits) that identifies
the Rails migration process as the owner of the lock. We multiply
this salt with a CRC32 unsigned integer hash of the database name to
get a signed 64 bit integer that can also be converted to a string
to act as a lock key in MySQL databases.
- It is important for subsequent versions of the Migrator to use the
same salt, otherwise different versions of the Migrator will not see
each other's locks.
|
|\
| |
| |
| | |
Add missed available transformations to Migration Doc [ci skip]
|
| |
| |
| |
| | |
[ci skip]
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
`alias :migrations_path= :migrations_paths=`, so
`migrations_path = some_string` is correct.
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
The last call site of `last_version` was removed with:
838e18321118ee3ec6669217e5ea0216f79c969a
|
| |
| |
| |
| | |
This method is private API and never used. Let's remove it.
|
| |
| |
| |
| |
| |
| | |
This change allows to instantiate all ActiveRecordError descendant
execption classes without arguments, which might be useful in testing
and is far less surprising than mandatory arguments.
|
|\ \
| | |
| | |
| | | |
Add detailed error message to `IrreversibleMigration`
|
| | | |
|
|\ \ \
| |/ /
|/| | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Use `ActiveRecord::Migration#connection` instead of `@connection`
|
| | | |
| | | |
| | | |
| | | |
| | | | |
`ActiveRecord::Migration` has `connetion` method so replace to use
`connection` method to get `@connection` as much as possible
|
| |/ /
|/| |
| | |
| | | |
In rails generally migration file's timestamp is "YYYYMMDDHHMMSS".
|
|/ / |
|
| | |
|
|\ \
| | |
| | | |
Add Docs for ActiveRecord #check_pending [ci skip]
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| | |
remove_foreign_key methods
fix tests
|
|\ \
| | |
| | |
| | | |
Update documentation for ActiveRecord::Migration#remove_index
|
| |/
| |
| |
| | |
`remove_index` works with multiple column names as `add_index`
|
|\ \
| |/
|/|
| |
| |
| | |
Add RDoc about add_reference to ActiveRecord::Migration
[ci skip]
|
|/
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
| |
Stems from https://github.com/rails/rails/pull/20105#issuecomment-100900939
where @senny said:
> From my point of view, all the docs (guides, API) are version bound.
> They should describe that version and continue to be available when newer versions are released.
> The cross referencing can be done by the interested user.
|
| |
|