- 19 10月, 2016 1 次提交
-
-
由 yuuji.yaginuma 提交于
Follow up to #20018.
-
- 01 10月, 2016 1 次提交
-
-
由 Lars Kanis 提交于
Zlib is used to generate the advisory lock since commit 2c2a8755 . 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.
-
- 14 9月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
All indentation was normalized by rubocop auto-correct at 80e66cc4. But comments was still kept absolute position. This commit aligns comments with method definitions for consistency.
-
- 16 8月, 2016 1 次提交
-
-
由 Rafael Mendonça França 提交于
Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
-
- 07 8月, 2016 4 次提交
-
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
-
- 25 7月, 2016 1 次提交
-
-
由 Xavier Noria 提交于
-
- 24 7月, 2016 1 次提交
-
-
由 Xavier Noria 提交于
Where appropriatei, prefer the more concise Regexp#match?, String#include?, String#start_with?, or String#end_with?
-
- 21 7月, 2016 1 次提交
-
-
由 Étienne Barrié 提交于
-
- 13 5月, 2016 1 次提交
-
-
由 Kang-Kyu Lee 提交于
-
- 03 5月, 2016 1 次提交
-
-
由 Erol Fornoles 提交于
-
- 01 5月, 2016 1 次提交
-
-
由 Jon Moss 提交于
Rails should not be explicity mentioned within Active Record, since railties and the Rails ecosystem is not required for use.
-
- 30 4月, 2016 1 次提交
-
-
由 yui-knk 提交于
`ActiveRecord::Migration` needn't know about migration version compatibility lookup. Delegate it to the Compatibility module. Signed-off-by: NJeremy Daer <jeremydaer@gmail.com>
-
- 10 4月, 2016 1 次提交
-
-
由 Prathamesh Sonpatki 提交于
-
- 24 3月, 2016 1 次提交
-
-
由 yui-knk 提交于
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.
-
- 14 3月, 2016 1 次提交
-
-
由 Gaurish Sharma 提交于
-
- 19 1月, 2016 1 次提交
-
-
由 yuuji.yaginuma 提交于
It has been to use an overall rails command in ea4f0e2b, in order to unify.
-
- 15 1月, 2016 2 次提交
-
-
由 Sean Griffin 提交于
- 12 1月, 2016 3 次提交
-
-
由 schneems 提交于
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.
-
由 schneems 提交于
-
由 schneems 提交于
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
-
- 09 1月, 2016 2 次提交
- 08 1月, 2016 3 次提交
-
-
由 schneems 提交于
Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035
-
由 schneems 提交于
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.
-
由 schneems 提交于
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`.
-
- 31 12月, 2015 1 次提交
-
-
由 Prathamesh Sonpatki 提交于
- So that we can just copy paste the command and execute it
-
- 18 12月, 2015 1 次提交
-
-
由 David Heinemeier Hansson 提交于
Still more to do. Please assist!
-
- 15 12月, 2015 4 次提交
-
-
由 Matthew Draper 提交于
Even though this means more things to change when we bump after a release, it's more important that our examples are directly copyable.
-
由 Matthew Draper 提交于
-
由 Matthew Draper 提交于
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.
-
由 Matthew Draper 提交于
-
- 18 11月, 2015 1 次提交
-
-
由 Sam Davies 提交于
- 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
-
- 09 11月, 2015 1 次提交
-
-
由 yui-knk 提交于
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?`.
-
- 02 11月, 2015 1 次提交
-
-
由 yui-knk 提交于
`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 ```
-
- 31 10月, 2015 1 次提交
-
-
由 Sam Davies 提交于
- 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.
-
- 02 10月, 2015 1 次提交
-
-
由 yui-knk 提交于
`alias :migrations_path= :migrations_paths=`, so `migrations_path = some_string` is correct.
-