| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Follow up to #20018.
|
|
|
|
|
|
|
|
|
| |
Zlib is used to generate the advisory lock since commit 2c2a8755460 .
Using the Migrator fails since then, when it is called without the rails context:
NameError: uninitialized constant ActiveRecord::Migrator::Zlib
This patch fixes the above error.
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
| |
Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Rails should not be explicity mentioned within Active Record, since
railties and the Rails ecosystem is not required for use.
|
|
|
|
|
|
|
| |
`ActiveRecord::Migration` needn't know about migration version
compatibility lookup. Delegate it to the Compatibility module.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
| |
database.
|
|\ |
|
| | |
|
|/
|
|
|
|
|
|
|
| |
`RuntimeError`
The error is raised because user passed invalid version number to a public api of
`ActiveRecord`, so `ArgumentError` is more suitable.
And add a test case checking if an error is raised when unknown migration version
is passed, because these test cases are not implemented.
|
|
|
|
| |
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.
|