- 22 2月, 2019 2 次提交
-
-
由 Ryuta Kamizono 提交于
I'm not sure why the test is failed on Travis, it passed on locally. I suspect that failure is a bug on SQLite3, so just skip the test for now, since it was not covered by before. https://travis-ci.org/rails/rails/jobs/496726410#L1198-L1208
-
由 Ryuta Kamizono 提交于
This is caused by 0ee96d13. Since #18744, `select` columns doesn't be qualified by table name if using `from`. 0ee96d13 follows that for `pluck` as well. But people depends that `pluck` columns are qualified even if using `from`. So I've fixed that to be qualified if `from` has the original table name to keep the behavior as much as before. Fixes #35359.
-
- 19 2月, 2019 1 次提交
-
-
由 Abhay Nikam 提交于
-
- 17 2月, 2019 2 次提交
-
-
由 Finn Young 提交于
-
由 Ryuta Kamizono 提交于
This follows up 0ee96d13.
-
- 15 2月, 2019 2 次提交
-
-
由 Ryuta Kamizono 提交于
This deprecates using class level querying methods if the receiver scope regarded as leaked, since #32380 and #35186 may cause that silently leaking information when people upgrade the app. We need deprecation first before making those.
-
由 Ryuta Kamizono 提交于
This reverts commit b67d5c6d, reversing changes made to 2e018361. Reason: #35186 may cause that silently leaking information when people upgrade the app. We need deprecation first before making this.
-
- 13 2月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
Currently custom attributes are always qualified by the table name in the generated SQL wrongly even if the table doesn't have the named column, it would cause an invalid SQL error. Custom attributes should only be qualified if the table has the same named column.
-
- 07 2月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
`relation.create` populates scope attributes to new record by `scoping`, it is necessary to assign the scope attributes to the record and to find STI subclass from the scope attributes. But the effect of `scoping` is class global, it was caused undesired behavior that pollute all class level querying methods in initialization block and callbacks (`after_initialize`, `before_validation`, `before_save`, etc), which are user provided code. To avoid the leaking scope issue, restore the original current scope before initialization block and callbacks are invoked. Fixes #9894. Fixes #17577. Closes #31526.
-
- 06 2月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
This follows up d97980a1.
-
- 08 12月, 2018 1 次提交
-
-
由 Bogdan 提交于
* `#create_or_find_by/!`: add more tests * Fix docs of `create_or_find_by` This method uses `find_by!` internally.
-
- 09 10月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
The delegation methods to named scope are defined when `method_missing` is invoked on the relation. Since #29301, the receiver in the named scope is changed to the relation like others (e.g. `default_scope`, etc) for consistency. Most named scopes would be delegated from relation by `method_missing`, since we don't allow scopes to be defined which conflict with instance methods on `Relation` (#31179). But if a named scope is defined with the same name as any method on the `superclass` (e.g. `Kernel.open`), the `method_missing` on the relation is not invoked. To address the issue, make the delegation methods to named scope is generated in the definition time. Fixes #34098.
-
- 16 9月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
`persistence_test.rb` and `relations_test.rb` have too many lines, so I'd like to extract relation around tests to dedicated files before newly test added.
-
- 11 9月, 2018 1 次提交
-
-
由 Darwin D Wu 提交于
In order to avoid double assignments of nested_attributes for `has_many` relations during record initialization, nested_attributes in `create_with` should not be passed into `klass.new` and have them populate during `initialize_internals_callback` with scope attributes. However, `create_with` keys should always have precedence over where clauses, so if there are same keys in both `create_with` and `where_values_hash`, the value in `create_with` should be the one that's used.
-
- 31 8月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
This restores an ability that `update` with ids on a relation which is described at https://github.com/rails/rails/issues/33470#issuecomment-411203013. I personally think that the `update` with two arguments on a relation is not a designed feature, since that is totally not using a relation state, and also is not documented. But removing any feature should not be suddenly happened in a stable version even if that is not documented.
-
- 31 7月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
Since 9ac7dd47, class level `update`, `destroy`, and `delete` were placed in the `Persistence` module as class methods. But `Relation#update` without passing ids which was introduced at #11898 is not a class method, and it was caused the extra scoping regression #33470. I moved the relation method back into the `Relation` to fix the regression. Fixes #33470.
-
- 19 4月, 2018 1 次提交
-
-
由 Daniel Colson 提交于
This autocorrects the violations after adding a custom cop in 3305c78dcd.
-
- 13 4月, 2018 1 次提交
-
-
由 fatkodima 提交于
-
- 15 2月, 2018 1 次提交
-
-
由 David Heinemeier Hansson 提交于
Add #create_or_find_by to lean on unique constraints
-
- 26 1月, 2018 4 次提交
-
-
由 Daniel Colson 提交于
-
由 Daniel Colson 提交于
-
由 Daniel Colson 提交于
-
由 Daniel Colson 提交于
-
- 25 1月, 2018 2 次提交
-
-
由 Ryuta Kamizono 提交于
This is a regression caused by 6beb4de7. In PostgreSQL, ORDER BY expressions must appear in SELECT list when using DISTINCT. When using `count(:all)` with eager loading, Active Record enforces DISTINCT to count the driving table records only. 6beb4de7 was caused the regression because `count(:all)` with DISTINCT path no longer removes ORDER BY. We need to ignore ORDER BY when DISTINCT is enforced, otherwise not always generated valid SQL for PostgreSQL. Fixes #31783.
-
由 Daniel Colson 提交于
Most of the time the table and predicate_builder passed to Relation.new are exactly the arel_table and predicate builder of the given klass. This uses klass.arel_table and klass.predicate_builder as the defaults, so we don't have to pass them in most cases. This does change the signaure of both Relation and AssocationRelation. Are we ok with that?
-
- 20 12月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
Currently `count(:all)` with `distinct` doesn't work correctly because SELECT list is always replaced to `*` or primary key in that case even if having custom SELECT list. And also, PostgreSQL has a limitation that ORDER BY expressions must appear in select list for SELECT DISTINCT. Therefore, we should not replace custom SELECT list when using `count(:all)` with `distinct`. Closes #31277.
-
- 19 12月, 2017 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
Arel doesn't support subselect generation for DELETE unlike UPDATE yet, but we already have that generation in connection adapters. We can simply use the subselect generated by that one.
-
- 08 12月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
This regression was caused at 213796fb due to polymorphic predicates are combined by `Arel::Nodes::And`. But I'd like to keep that combined because it would help inverting polymorphic predicates correctly (e9ba12f7), and we can collect equality nodes regardless of combined by `Arel::Nodes::And` (`a AND (b AND c) AND d` == `a AND b AND c AND d`). This change fixes the regression to collect equality nodes in `Arel::Nodes::And` as well. Fixes #31338.
-
- 10 11月, 2017 2 次提交
-
-
由 Ryuta Kamizono 提交于
Fixes #21577.
- 09 11月, 2017 7 次提交
- 09 10月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 30 9月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
-