- 26 11月, 2015 1 次提交
-
-
由 Jared Beck 提交于
[ci skip]
-
- 24 11月, 2015 3 次提交
-
-
由 Ryuta Kamizono 提交于
Not needed for `Mysql2Adapter` and `AbstractMysqlAdapter`.
-
由 Ryuta Kamizono 提交于
-
由 Sean Griffin 提交于
As was pointed out by #17128, our blacklist of mutation methods was non-exhaustive (and would need to be kept up to date with each new version of Ruby). Now that `Relation` includes `Enumerable`, the number of methods that we actually need to delegate are pretty small. As such, we can change to explicitly delegating the few non-mutation related methods that `Array` has which aren't on `Enumerable`
-
- 21 11月, 2015 1 次提交
-
-
由 Ryan Bigg 提交于
-
- 20 11月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
This reverts commit 8246b593. There was concern about this modifying the behavior of past migrations. We're going to add an way to modify the migration generator instead.
-
由 Sean Griffin 提交于
It's often the case that you want to have an option that you cannot specify at the database level, but want applied to *all* tables that you create. For example, you might want to specify `ROW_FORMAT=DYNAMIC` to not have to limit text columns to length 171 for indexing when using utf8mb4. This allows an easy way to specify this in your database configuration. While this change affects both MySQL and MySQL2, the test only covers MySQL2, as the legacy mysql adapter appears to always return ASCII strings, and is tangential to what we're actually doing.
-
- 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
-
- 17 11月, 2015 1 次提交
-
-
由 Andrew White 提交于
In b71e08f8 we started raising when nil or false was passed to merge to fix #12264, however we should also do this for truthy values that are invalid like true.
-
- 16 11月, 2015 3 次提交
-
-
由 yui-knk 提交于
If argument of `build_record` has key and value which is same as default value of database, we should also except the key from `create_scope` in `initialize_attributes`. Because at first `build_record` initialize record object with argument of `build_record`, then assign attributes derived from Association's scope. In this case `record.changed` does not include the key, which value is same as default value of database, so we should add the key to except list. Fix #21893.
-
由 Sean Griffin 提交于
The string returned here will ultimately get used as a key of a hash in the attribute set once the attributes are being built. When you give a non-frozen string to `Hash#[]`, it will be duped. Be freezing we can significantly reduce the number of times we end up allocating `"user_id"` This does not include any additional tests, as this should not have any public facing implications. If you are mutating the result of `Reflection#foreign_key`, please stop.
-
由 Ryuta Kamizono 提交于
-
- 12 11月, 2015 1 次提交
-
-
由 yui-knk 提交于
From Ruby ( 2.3.0dev trunk 52520), `Hash#to_proc` is defined (https://github.com/ruby/ruby/commit/fbe967ec02cb65a7efa3fb8f3d747cf6f620dde1), and many tests have been failed with `ArgumentError: wrong number of arguments (given 0, expected 1)`. Because we call `Hash#to_proc` with no args in `#merge!`. This commit changes order of conditionals to not call `Hash#to_proc`.
-
- 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?`.
-
- 08 11月, 2015 7 次提交
-
-
由 Kassio Borges 提交于
Skipping `marked_for_destruction?` when the associated object does not responds to it make easier to validate virtual associations built on top of Active Model objects and/or serialized objects that implement a `valid?` instance method.
-
由 Ehsan Yousefi 提交于
There is no need to to assign reflection name to a variable, because it's called once.
-
由 Yves Senn 提交于
[ci skip] There was a `ActiveRecord::Relation::RecordFetchWarning::ActiveSupport` artifact caused by subscribing to AS notifications.
-
由 Ryuta Kamizono 提交于
The `native_database_types` only used in `TableDefinition` for look up the default `:limit` option. But this is duplicated process with `type_to_sql`. Passing `native_database_types` is not needed.
-
由 Yves Senn 提交于
This type is backed by a class macro. Documentation related to the type casting behavior should be added in the macro description.
-
由 Yves Senn 提交于
[ci skip] While `JoinDependency` and `JoinDependency::Aliases` were nodoced, the inner `Table` class made them appear in the API.
-
由 Yves Senn 提交于
[ci skip]
-
- 07 11月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
I've added a redundant test for this under the attributes API as well, as that also causes this bug to manifest through public API (and demonstrates that calling `reset_column_information` on the child classes would be insufficient) Since children of a class should always share a table with their parent, just reloading the schema from the cache should be sufficient here. `reload_schema_from_cache` should probably become public and `# :nodoc:`, but I'd rather avoid the git churn here. Fixes #22057
-
由 Kevin Buchanan 提交于
-
- 05 11月, 2015 1 次提交
-
-
由 Jerry D'Antonio 提交于
-
- 04 11月, 2015 2 次提交
-
-
由 Andrew White 提交于
Columns are no longer stored in an attribute since b8a533d5. [ci skip]
-
由 Thomas Walpole 提交于
Add AC::Parameters tests for WhereChain#not
-
- 03 11月, 2015 1 次提交
-
-
由 Yuki Nishijima 提交于
-
- 02 11月, 2015 4 次提交
-
-
由 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 ```
-
由 Ryuta Kamizono 提交于
Such as #10404, #18206.
-
由 Ryuta Kamizono 提交于
This reverts commit f6ca7e4e. The default collation of utf8 in MySQL is the `utf8_general_ci`, and this should not be changed. This is because, the better collation in the all locales is not exists, optimal collation in own application is not known other than themselves. The `utf8_unicode_ci` is known as Japanese killer in Japan, there are serious impacts in search of Japanese. MySQL implements the `utf8_unicode_ci` according to the Unicode Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/, but the `utf8_unicode_ci` have only partial support for the UCA, only primary level key comparison implemented (also known as L1 (Base characters) comparison). Because L1 (Base characters) comparison does not distinguish between the presence or absence of the accent, if distinction of the accent is important there is a serious impact (e.g. Japanese). Example: ``` > SHOW CREATE TABLE `dicts`\G *************************** 1. row *************************** Table: dicts Create Table: CREATE TABLE `dicts` ( `word` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, `meaning` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci 1 row in set (0.00 sec) > INSERT INTO `dicts` VALUES ('ハハ', 'mother'), ('パパ', 'father'); Query OK, 2 rows affected (0.00 sec) > SELECT * FROM `dicts` WHERE `word` = 'ハハ'; +--------+---------+ | word | meaning | +--------+---------+ | ハハ | mother | | パパ | father | +--------+---------+ 2 rows in set (0.00 sec) > CREATE UNIQUE INDEX `unique_index_word` ON `dicts`(`word`); ERROR 1062 (23000): Duplicate entry 'ハハ' for key 'unique_index_word' ``` We should omit the collation entirely rather than providing a default. Then the choice is the responsibility of the server and MySQL distribution.
-
- 31 10月, 2015 2 次提交
-
-
由 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.
-
由 Takashi Kokubun 提交于
-
- 30 10月, 2015 6 次提交
-
-
由 Sean Griffin 提交于
Before this commit, if `ActiveRecord::Base.belongs_to_required_by_default` is set to `true`, then creating a record through `has_and_belongs_to_many` fails with the cryptic error message `Left side must exist`. This is because `inverse_of` isn't working properly in this case, presumably since we're doing trickery with anonymous classes in the middle. Rather than following this rabbit hole to try and get `inverse_of` to work in a case that we know is not publicly supported, we can just turn off this validation to match the behavior of 4.2 and earlier.
-
由 Harry Marr 提交于
-
由 Sean Griffin 提交于
This is part of a refactoring to make it easier to allow `order` to use sanitize like just about everything else on relation. The deleted test doesn't give any reasoning as to why passing `nil` to `order` needs to be supported, and it's rather nonsensical. I can almost see allowing an empty string being passed (though I'm tempted to just disallow it...)
-
由 Jamis Buck 提交于
Look at `TestFixtures.set_fixture_class`. As documented, it accepts a mapping of fixture identifiers (string or symbol) to Classes (the model classes that implement the named fixture). Look now at the initialization of `TestFixtures.fixture_class_names`. It defines a Hash, which will return a string by default (where the string is the estimated class name of the given fixture identifier). Now look at TestFixtures.load_fixtures. It calls `FixtureSet.create_fixtures`, passing in the mapping of `fixture_class_names`. Following this on to `FixtureSet.create_fixtures`, this instantiates a `FixtureSet::ClassCache`, passing in the map of class names. `ClassCache`, in turn, calls `insert_class` for each value in the cache. (Recall that `set_fixture_class` puts Class objects in there, while the default proc for the mapping puts String objects.) Look finally at `insert_class`. If the value is present, it checks to see if the value is a subclass of `AR::Base`. Fair enough...but wait! What if the value is a String? You get an exception, because a String instance cannot be compared with a Class. Judging from the implementation, it seems like the expected behavior here is for `fixture_class_names` to have no default proc. Look-ups are supposed to happen via `ClassCache`, with `fixture_class_names` existing solely as a repository for explicitly-registered class mappings. That is what this change does.
-
由 Sean Griffin 提交于
This reverts commit 6dc6a0b1, reversing changes made to ec94f00b. This pull request broke the build.
-
- 29 10月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
We don't need to use `String#+` or create all the intermediate strings to break a string into multiple lines. We can just write a c-style multiline string literal. This is by no means a hotpath, but this is clearer to me anyway.
-