aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #35503 from samjohn/cannot-grammar-correctionXavier Noria2019-03-072-2/+2
|\ | | | | Replace “can not” with “cannot”.
| * Replace “can not” with “cannot”.Samantha John2019-03-062-2/+2
| |
* | Fix incorrect identifier quoting [ci skip]Ryuta Kamizono2019-03-071-2/+2
|/
* Relax table name detection in `from` to allow any extension like INDEX hintRyuta Kamizono2019-03-011-2/+5
| | | | | | | | | | #35360 allows table name qualified if `from` has original table name. But that is still too strict. We have a valid use case that `from` with INDEX hint (e.g. `from("comments USE INDEX (PRIMARY)")`). So I've relaxed the table name detection in `from` to allow any extension like INDEX hint. Fixes #35359.
* Merge pull request #33611 from willianveiga/feature/reselect-methodAndrew White2019-03-011-0/+21
|\ | | | | Add reselect method
| * Avoid creating an extra relation instanceWillian Gustavo Veiga2018-10-241-2/+9
| |
| * Merge branch 'master' into feature/reselect-methodWillian Gustavo Veiga2018-10-221-10/+8
| |\
| * \ Merge branch 'master' into feature/reselect-methodWillian Gustavo Veiga2018-10-111-0/+30
| |\ \
| * \ \ Merge branch 'master' into feature/reselect-methodWillian Gustavo Veiga2018-10-027-24/+30
| |\ \ \
| * | | | Add reselect methodWillian Gustavo Veiga2018-08-131-0/+14
| | | | |
* | | | | [ci skip] The `find` method coerces the given arguments to integer if the ↵Mehmet Emin INAC2019-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | `primary key` is integer
* | | | | [ci skip] Fix the documentation of ActiveRecord::FinderMethods#findMehmet Emin INAC2019-02-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's mentioned everywhere as `ActiveRecord::RecordNotFound` so to be coherent with the rest of the documentation I've applied it here. Also doc was saying if the parameter is integer it coerces it which is other way around.
* | | | | Refactor `generated_relation_methods` to remove duplicated code on ↵Ryuta Kamizono2019-02-281-31/+20
| | | | | | | | | | | | | | | | | | | | `ClassSpecificRelation`
* | | | | fixes different `count` calculation when using `size` manual `select` with ↵jvillarejo2019-02-261-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DISTINCT When using `select` with `'DISTINCT( ... )'` if you use method `size` on a non loaded relation it overrides the column selected by passing `:all` so it returns different value than count. This fixes #35214
* | | | | Fix `pluck` and `select` with `from` if `from` has original table nameRyuta Kamizono2019-02-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is caused by 0ee96d1. Since #18744, `select` columns doesn't be qualified by table name if using `from`. 0ee96d1 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.
* | | | | Fix lint `ShadowingOuterLocalVariable`soartec-lab2019-02-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert "Fix lint `ShadowingOuterLocalVariable`" This reverts commit 38bd45a48992b500478a82d56d31468a322937a8. Change of variable name Fix lint `ShadowingOuterLocalVariable`
* | | | | Don't allow `where` with invalid value matches to nil valuesRyuta Kamizono2019-02-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That is considered as silently leaking information. If type casting doesn't return any actual value, it should not be matched to any record. Fixes #33624. Closes #33946.
* | | | | Fix eager loading polymorphic association with mixed table conditionsRyuta Kamizono2019-02-181-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a bug that the `foreign_key` and the `foreign_type` are separated as different table conditions if a polymorphic association has a scope that joins another tables.
* | | | | Merge pull request #35274 from AlexBrodianoi/fix_does_not_support_reverseRyuta Kamizono2019-02-171-1/+1
|\ \ \ \ \ | | | | | | | | | | | | Raise ActiveRecord::IrreversibleOrderError if nulls first/last is not a single ordering argument.
| * | | | | Raise ActiveRecord::IrreversibleOrderError if nulls first/last is not a ↵Finn Young2019-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | single ordering argument.
* | | | | | Fix `order` with custom attributesRyuta Kamizono2019-02-171-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | This follows up 0ee96d13de29680e148ccb8e5b68025f29fd091c.
* | | | | | Deprecate using class level querying methods if the receiver scope regarded ↵Ryuta Kamizono2019-02-151-1/+1
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as leaked 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.
* | | | | Revert "Chaining named scope is no longer leaking to class level querying ↵Ryuta Kamizono2019-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | methods" This reverts #32380, since this may cause that silently leaking information when people upgrade the app. We need deprecation first before making this.
* | | | | Fix `pluck` and `select` with custom attributesRyuta Kamizono2019-02-132-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | Fix `relation.exists?` with giving both `distinct` and `offset`Ryuta Kamizono2019-02-081-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `distinct` affects (reduces) rows of the result, so it is important part when both `distinct` and `offset` are given. Replacing SELECT clause to `1 AS one` and removing `distinct` and `order` is just optimization for the `exists?`, we should not apply the optimization for that case. Fixes #35191.
* | | | | Refactor around scopingRyuta Kamizono2019-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use `false` as special value to skip to find inherited scope, we could use `skip_inherited_scope = true`, and move `_scoping` back on Relation.
* | | | | Relation no longer respond to Arel methodsRyuta Kamizono2019-02-061-1/+1
| | | | | | | | | | | | | | | | | | | | This follows up d97980a16d76ad190042b4d8578109714e9c53d0.
* | | | | Chaining named scope is no longer leaking to class level querying methodsRyuta Kamizono2019-02-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Active Record uses `scoping` to delegate to named scopes from relations for propagating the chaining source scope. It was needed to restore the source scope in named scopes, but it was caused undesired behavior that pollute all class level querying methods. Example: ```ruby class Topic < ActiveRecord::Base scope :toplevel, -> { where(parent_id: nil) } scope :children, -> { where.not(parent_id: nil) } scope :has_children, -> { where(id: Topic.children.select(:parent_id)) } end # Works as expected. Topic.toplevel.where(id: Topic.children.select(:parent_id)) # Doesn't work due to leaking `toplevel` to `Topic.children`. Topic.toplevel.has_children ``` Since #29301, the receiver in named scopes has changed from the model class to the chaining source scope, so the polluting class level querying methods is no longer required for that purpose. Fixes #14003.
* | | | | activerecord: Fix statement cache for strictly cast attributesDylan Thacker-Smith2019-01-231-1/+1
| | | | |
* | | | | activerecord: Fix where nil condition on composed_of attributeDylan Thacker-Smith2019-01-181-4/+5
| | | | |
* | | | | All of queries should return correct result even if including large numberRyuta Kamizono2019-01-181-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently several queries cannot return correct result due to incorrect `RangeError` handling. First example: ```ruby assert_equal true, Topic.where(id: [1, 9223372036854775808]).exists? assert_equal true, Topic.where.not(id: 9223372036854775808).exists? ``` The first example is obviously to be true, but currently it returns false. Second example: ```ruby assert_equal topics(:first), Topic.where(id: 1..9223372036854775808).find(1) ``` The second example also should return the object, but currently it raises `RecordNotFound`. It can be seen from the examples, the queries including large number assuming empty result is not always correct. Therefore, This change handles `RangeError` to generate executable SQL instead of raising `RangeError` to users to always return correct result. By this change, it is no longer raised `RangeError` to users.
* | | | | Use `unboundable?` rather than `boundable?`Ryuta Kamizono2019-01-181-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `unboundable?` behaves like the `infinite?`. ```ruby inf = Topic.predicate_builder.build_bind_attribute(:id, Float::INFINITY) inf.infinite? # => 1 oob = Topic.predicate_builder.build_bind_attribute(:id, 9999999999999999999999999999999) oob.unboundable? # => 1 inf = Topic.predicate_builder.build_bind_attribute(:id, -Float::INFINITY) inf.infinite? # => -1 oob = Topic.predicate_builder.build_bind_attribute(:id, -9999999999999999999999999999999) oob.unboundable? # => -1 ```
* | | | | Merge pull request #34963 from ↵Rafael França2019-01-171-8/+12
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | dylanahsmith/better-composed-of-single-field-query activerecord: Use a simpler query condition for aggregates with one mapping
| * | | | | Use public_send instead since respond_to? doesn't include private/protected ↵Ryuta Kamizono2019-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | methods by default Co-Authored-By: dylanahsmith <dylan.smith@shopify.com>
| * | | | | Avoid using yield_self to make it easier to backportDylan Thacker-Smith2019-01-171-5/+4
| | | | | |
| * | | | | activerecord: Use a simpler query condition for aggregates with one mappingDylan Thacker-Smith2019-01-171-8/+13
| | | | | |
* | | | | | Do not allow passing the column name to `sum` when a block is passedRafael Mendonça França2019-01-171-6/+4
| | | | | |
* | | | | | Do not allow passing the column name to `count` when a block is passedRafael Mendonça França2019-01-171-6/+4
| | | | | |
* | | | | | Remove delegation of missing methods in a relation to arelRafael Mendonça França2019-01-171-4/+0
| | | | | |
* | | | | | Remove delegation of missing methods in a relation to private methods of the ↵Rafael Mendonça França2019-01-171-5/+0
|/ / / / / | | | | | | | | | | | | | | | class
* | | | | Merge branch 'master' into ac_params_existsAaron Patterson2019-01-112-24/+5
|\ \ \ \ \
| * | | | | Consolidate the duplicated code that building range predicateRyuta Kamizono2019-01-082-24/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This slightly change the code in the Arel to allow +/-INFINITY as open ended since the Active Record expects that behavior. See 5ecbeda.
* | | | | | Allow strong params in ActiveRecord::Base#exists?Gannon McGibbon2019-01-071-0/+2
|/ / / / / | | | | | | | | | | | | | | | | | | | | Allow `ActionController::Params` as argument of `ActiveRecord::Base#exists?`
* | | | | Make average compatible accross Ruby versionsAlberto Almagro2019-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Ruby 2.6.0 NilClass#to_d is returning `BigDecimal` 0.0, this breaks `average` compatibility with prior Ruby versions. This patch makes `average` return `nil` in all Ruby versions when there are no rows.
* | | | | Fix TypeError: no implicit conversion of Arel::Attributes::Attribute into ↵Ryuta Kamizono2019-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | String properly This reverts 27c6c07 since `arel_attr.to_s` is not right way to avoid the type error. That to_s returns `"#<struct Arel::Attributes::Attribute ...>"`, there is no reason to match the regex to the inspect form. And also, the regex path is not covered by our test cases. I've tweaked the regex for redundant part and added assertions for the regex path.
* | | | | Module#{define_method,alias_method,undef_method,remove_method} become public ↵Ryuta Kamizono2018-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | since Ruby 2.5 https://bugs.ruby-lang.org/issues/14133
* | | | | Fix the scoping with query methods in the scope blockRyuta Kamizono2018-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow up #33394. #33394 only fixes the case of scoping with klass methods in the scope block which invokes `klass.all`. Query methods in the scope block also need to invoke `klass.all` to be affected by the scoping.
* | | | | Make implicit order column configurableTekin Suleyman2018-11-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling ordered finder methods such as +first+ or +last+ without an explicit order clause, ActiveRecord sorts records by primary key. This can result in unpredictable and surprising behaviour when the primary key is not an auto-incrementing integer, for example when it's a UUID. This change makes it possible to override the column used for implicit ordering such that +first+ and +last+ will return more predictable results. For Example: class Project < ActiveRecord::Base self.implicit_order_column = "created_at" end
* | | | | Arel: Implemented DB-aware NULL-safe comparison (#34451)Dmytro Shteflyuk2018-11-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Arel: Implemented DB-aware NULL-safe comparison * Fixed where clause inversion for NULL-safe comparison * Renaming "null_safe_eq" to "is_not_distinct_from", "null_safe_not_eq" to "is_distinct_from" [Dmytro Shteflyuk + Rafael Mendonça França]
* | | | | Ignore empty condition on #construct_relation_for_existsr7kamura2018-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At https://github.com/rails/rails/commit/fc0e3354af7e7878bdd905a95ce4c1491113af9a, ```rb relation = relation.where(conditions) ``` was rewritten to: ```rb relation.where!(condition) ``` This change accidentally changed the result of `Topic.exists?({})` from true to false. To fix this regression, first I moved the blank check logic (`opts.blank?`) from `#where` to `#where!`, because I thought `#where!` should be identical to `#where`, except that instead of returning a new relation, it adds the condition to the existing relation. But on second thought after some discussion on https://github.com/rails/rails/pull/34329, I started to think that just fixing `#construct_relation_for_exists` is more preferable than changing `#where` and `#where!`.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 05:21:38 +0000