- 15 12月, 2015 1 次提交
-
-
由 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.
-
- 28 9月, 2015 1 次提交
-
-
由 amitkumarsuroliya 提交于
-
- 09 9月, 2015 2 次提交
-
-
由 Yves Senn 提交于
This method is private API and never used. Let's remove it.
- 07 9月, 2015 1 次提交
-
-
由 Pavel Pravosud 提交于
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.
-
- 29 8月, 2015 1 次提交
-
-
由 yui-knk 提交于
-
- 24 8月, 2015 2 次提交
- 23 8月, 2015 2 次提交
- 21 8月, 2015 1 次提交
-
-
由 Yves Senn 提交于
-
- 18 8月, 2015 1 次提交
-
-
由 ravindra kumar kumawat 提交于
-
- 07 8月, 2015 1 次提交
-
-
由 Brendan Buckingham 提交于
-
- 23 7月, 2015 1 次提交
-
-
由 Mauro George 提交于
[ci skip]
-
- 25 6月, 2015 1 次提交
-
-
由 Mehmet Emin İNAÇ 提交于
fix tests
-
- 14 6月, 2015 1 次提交
-
-
由 Mauro George 提交于
[ci skip]
-
- 22 5月, 2015 1 次提交
-
-
由 Aleksandar Diklic 提交于
`remove_index` works with multiple column names as `add_index`
-
- 12 5月, 2015 1 次提交
-
-
由 claudiob 提交于
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.
-
- 11 5月, 2015 1 次提交
-
-
由 claudiob 提交于
-
- 24 2月, 2015 1 次提交
-
-
由 Luke Hutscal 提交于
I think this was supposed to be "roundTrip".
-
- 19 2月, 2015 1 次提交
-
-
由 Daniël de Vries 提交于
-
- 02 1月, 2015 1 次提交
-
-
由 Rafael Mendonça França 提交于
This constant may be define for auxiliar gems like rails-html-sanitizer and these methods call will fail.
-
- 29 11月, 2014 1 次提交
-
-
由 Erik Michaels-Ober 提交于
-
- 26 11月, 2014 1 次提交
-
-
由 Yves Senn 提交于
This reverts deprecations added in #13528. The task is brought back for two reasons: 1. Give plugins a way to hook into the test database initialization process 2. Give the user a way to force a test database synchronization While `test:prepare` is still a dependency of every test task, `db:test:prepare` no longer hooks into it. This means that `test:prepare` runs before the schema is synchronized. Plugins, which insert data can now hook into `db:test:prepare`. The automatic schema maintenance can't detect when a migration is rolled-back, modified and reapplied. In this case the user has to fall back to `db:test:prepare` to force the synchronization to happen.
-
- 24 11月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 01 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
Fixes #17170
-
- 21 8月, 2014 2 次提交
-
-
由 Aditya Kapoor 提交于
-
由 Aditya Kapoor 提交于
-
- 14 8月, 2014 1 次提交
-
-
由 Jeremy McNevin 提交于
This method would assume that if last migration in the migrations directory matched the current schema version, that the database was up to date, but this does not account for new migrations with older timestamps that may be pending.
-
- 06 8月, 2014 1 次提交
-
-
由 Yves Senn 提交于
The rake tasks and the `DatabaseTakss` adapter classes used to assume a configuration at some places. This forced the rake tasks to establish a specific connection before calling into `load_schema`. After #15394 this started to cause issues because it could `purge` the wrong database before loading the schema.
-
- 31 7月, 2014 1 次提交
-
-
由 Jack Danger Canty 提交于
These are the only instances of this in the whole code base.
-
- 02 7月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 27 6月, 2014 1 次提交
-
-
由 Yves Senn 提交于
respect `table_name_prefix` and `table_name_suffix`.
-
- 06 6月, 2014 1 次提交
-
-
由 Yves Senn 提交于
The migration numbers were normalized different ways. This left the task output in an inconsistent state. Closes #15538.
-