- 21 3月, 2018 1 次提交
-
-
由 David Stosik 提交于
-
- 20 3月, 2018 1 次提交
-
-
由 David Stosik 提交于
When dumping the database schema, Rails will dump foreign key names only if those names were not generate by Rails. Currently this is determined by checking if the foreign key name is `fk_rails_` followed by a 10-character hash. At [Cookpad](https://github.com/cookpad), we use [Departure](https://github.com/departurerb/departure) (Percona's pt-online-schema-change runner for ActiveRecord migrations) to run migrations. Often, `pt-osc` will make a copy of a table in order to run a long migration without blocking it. In this copy process, foreign keys are copied too, but [their name is prefixed with an underscore to prevent name collision ](https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html#cmdoption-pt-online-schema-change-alter-foreign-keys-method). In the process described above, we often end up with a development database that contains foreign keys which name starts with `_fk_rails_`. That name does not match the ignore pattern, so next time Rails dumps the database schema (eg. when running `rake db:migrate`), our `db/schema.rb` file ends up containing those unwanted foreign key names. This also produces an unwanted git diff that we'd prefer not to commit. In this PR, I'd like to suggest a way to expose the foreign key name ignore pattern to the Rails configuration, so that individual projects can decide on a different pattern of foreign keys that will not get their names dumped in `schema.rb`.
-
- 19 3月, 2018 1 次提交
-
-
由 bogdanvlviv 提交于
This test fails in specific time. Example: If run this test on the machine with time 01:00 am UTC+2, this test will fail. Changing representing of 2000-01-01 01:00 am UTC+2 to UTC+0 change the day, month and even year in our case, so substitution `"2000-01-01 "` to `""` isn't possible. ``` Failure: ActiveRecord::ConnectionAdapters::QuotingTest#test_quoted_time_utc Expected: "1999-12-31 23:01:27" Actual: "23:01:27" ``` Related to 7c479cbf
-
- 18 3月, 2018 1 次提交
-
-
由 Saverio Miroddi 提交于
The current documentation explicitly mentions only PostgreSQL (hstore/json) for use with `.store_accessor`, making it somewhat confusing what to choose on a MySQL 5.7+ setup (which introduced a json data type).
-
- 17 3月, 2018 1 次提交
-
-
由 eileencodes 提交于
If you had a three-tier config, the `establish_connection` that's called in the Railtie on load can't figure out how to access the default configuration. This is because Rails assumes that the config is the first value in the hash and always associated with the key from the environment. With a three tier config however we need to go one level deeper. This commit includes 2 changes. 1) removes a line from `resolve_all` which was parsing out the the environment from the config so instead of getting ``` { :development => { :primary => { :database => "whatever" } }, :animals => { :database => "whatever-animals" } }, etc with test / prod } ``` We'd instead end up with a config that had no attachment to it's envioronment. ``` { :primary => { :database => "whatever" } :animals => { :database => "whatever-animals" } etc - without test and prod } ``` Not only did this mean that Active Record didn't know how to establish a connection, it didn't have the other necessary configs along with it in the configs list. So fix this I removed the line that deletes these configs. The second thing this commit changes is adding this line to `establish_connection` ``` spec = spec[spec_name.to_sym] if spec[spec_name.to_sym] ``` When you have a three-tier config and don't pass any hash/symbol/env etc to `establish_connection` the resolver will automatically return both the primary and secondary (in this case animals db) configurations. We'll get an `database configuration does not specify adapter` error because AR will try to establish a connection on the `primary` key rather than the `primary` key's config. It assumes that the `development` or default env automatically will return a config hash, but with a three-tier config we actually get a key and config `primary => config`. This fix is a bit of a bandaid because it's not the "correct" way to handle this situation, but it does solve our immediate problem. The new code here is saying "if the config returned from the resolver (I know it's called spec in here but we interchange our meanings a LOT and what is returned is a three-tier config) has a key matching the "primary" spec name, grab the config from the spec and pass that to the estalbish_connection method". This works because if we pass `:animals` or a hash, or `:primary` we'll already have the correct configuration to connect with. This fixes the case where we want Rail to connect with the default connection. Coming soon is a refactoring that should eliminate the need to do this but I need this fix in order to write the multi-db rake tasks that I promised in my RailsConf submission. `@tenderlove` and I are working on the refactoring of the internals for connection management but it won't be ready for a few weeks and this issue has been blocking progress.
-
- 16 3月, 2018 2 次提交
-
-
由 Rafael Mendonça França 提交于
[ci skip]
-
由 fatkodima 提交于
-
- 14 3月, 2018 1 次提交
-
-
由 Rafael Mendonça França 提交于
We only add the header when releasing to avoid some conflicts. [ci skip]
-
- 12 3月, 2018 3 次提交
-
-
由 Andrew White 提交于
In #24542, quoted_time was introduced to strip the leading date component for time columns because it was having a significant effect in mariadb. However, it assumed that the date component was always 2000-01-01 which isn't the case, especially if the source wasn't another time column.
-
由 Andrew White 提交于
For legacy reasons Rails stores time columns on sqlite as full timestamp strings. However because the date component wasn't being normalized this meant that when they were read back they were being prefixed with 2001-01-01 by ActiveModel::Type::Time. This had a twofold result - first it meant that the fast code path wasn't being used because the string was invalid and second it was corrupting the second fractional component being read by the Date._parse code path. Fix this by a combination of normalizing the timestamps on writing and also changing Active Model to be more lenient when detecting whether a string starts with a date component before creating the dummy time value for parsing.
-
由 Andrew White 提交于
In #20317, datetime columns had their precision applied on assignment but that behaviour wasn't applied to time columns - this commit fixes that. Fixes #30301.
-
- 09 3月, 2018 1 次提交
-
-
由 Yuji Hanamura 提交于
-
- 07 3月, 2018 1 次提交
-
-
由 Sean Griffin 提交于
This reverts commit a19e91f0.
-
- 06 3月, 2018 5 次提交
-
-
由 Fernando Gorodscy 提交于
When a class has a belongs_to or has_one relationship with dependent: :destroy option enabled, objects of this class should not be deleted if it's dependents cannot be deleted. Example: class Parent has_one :child, dependent: :destroy end class Child belongs_to :parent, inverse_of: :child before_destroy { throw :abort } end c = Child.create p = Parent.create(child: c) p.destroy p.destroyed? # expected: false; actual: true; Fixes #32022
-
由 Lachlan Sylvester 提交于
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
-
由 Ryuta Kamizono 提交于
This issue is caused by `@_trigger_update_callback` won't be updated due to `_update_record` in `Locking::Optimistic` doesn't call `super` when optimistic locking is enabled. Now optimistic locking concern when updating is supported by `_update_row` low level API, therefore overriding `_update_record` is no longer necessary. Removing the method just fix the issue. Closes #29096. Closes #29321. Closes #30823.
-
- 05 3月, 2018 6 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
Currently primary key value can not be updated if a record has a locking column because of `_update_record` in `Locking::Optimistic` doesn't respect `id_in_database` as primary key value unlike in `Persistence`. And also, if a record has dirty primary key value, it may destroy any other record by the lock version of dirty record itself. When updating/destroying persisted records, it should identify themselves by `id_in_database`, not by dirty primary key value.
-
- 04 3月, 2018 3 次提交
-
-
由 Ryuta Kamizono 提交于
This removes `|| id` which were added in #9963 and #23887 since it is no longer necessary.
-
由 Ryuta Kamizono 提交于
This reverts ignoring polymorphic error introduced at 02da8aea. What the ignoring want to solve was caused by force eager loading regardless of whether it is necessary, but it has been fixed by #29043. The ignoring is now only causing a mismatch of `exists?` behavior with `to_a`, `count`, etc. It should behave consistently.
-
由 Ryuta Kamizono 提交于
This is an alternative of #29722, and follow up of #32048. This does not change the current behavior, but makes it easier to modify all polymorphic names consistently.
-
- 03 3月, 2018 1 次提交
-
-
由 yuuji.yaginuma 提交于
Ruby 2.4+ provides `Hash#compact` and `Hash#compact!` natively, so `active_support/core_ext/hash/compact` is no longer necessary.
-
- 02 3月, 2018 6 次提交
-
-
由 yuuji.yaginuma 提交于
Since Rails 6 requires Ruby 2.4.1+.
-
由 yuuji.yaginuma 提交于
-
由 Ryuta Kamizono 提交于
This comment was added at 070dda28. That arguments has already been changed since those are internal nodoc classes, but the comment does not reflect the current state. I decided to remove the staled comment since it is not useful for understanding what the class does. [ci skip]
-
由 Ryuta Kamizono 提交于
Follow up of b988ecb9. This was added for internal usage, it doesn't need to be public.
-
由 Ryuta Kamizono 提交于
Duplicated method name list is no longer needed.
-
- 28 2月, 2018 5 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
There is no reason `attributes=` doesn't take `assign_attributes`.
-
由 Ryuta Kamizono 提交于
This was added in 9bfa13bb, but it is never used from the beginning.
-
由 okkez 提交于
columsn -> columns
-
由 bogdanvlviv 提交于
Related to 948b9319
-
- 27 2月, 2018 1 次提交
-
-
由 kg8m 提交于
Prevent `ActiveRecord::FinderMethods#limited_ids_for` from using correct primary key values even if `ORDER BY` columns include other table's primary key. Fixes #28364.
-