aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation
Commit message (Collapse)AuthorAgeFilesLines
* Deduplicate joins valuesRyuta Kamizono2019-08-021-3/+3
| | | | | | | | | #36805 have one possible regression that failing deduplication if `joins_values` have complex order (e.g. `joins_values = [join_node_a, :comments, :tags, join_node_a]`). This fixes the deduplication to take it in the first phase before grouping.
* Preserve user supplied joins order as much as possibleRyuta Kamizono2019-07-301-16/+30
| | | | | | | | | | | | | | Currently, string joins are always applied as last joins part, and Arel join nodes are always applied as leading joins part (since #36304), it makes people struggled to preserve user supplied joins order. To mitigate this problem, preserve the order of string joins and Arel join nodes either before or after of association joins. Fixes #36761. Fixes #34328. Fixes #24281. Fixes #12953.
* Merge pull request #36412 from robotdana/compact_blankRafael Mendonça França2019-07-251-6/+6
|\ | | | | | | Add compact_blank shortcut for reject(&:blank?)
| * Use compact_blank throughout railsDana Sherson2019-06-051-6/+6
| |
* | [ActiveRecord] Deduplicate optimizer hintsKir Shatrov2019-07-191-1/+1
| |
* | Merge pull request #36647 from ↵Ryuta Kamizono2019-07-111-1/+1
|\ \ | | | | | | | | | | | | | | | giraffate/fix_exists_with_distinct_and_offset_and_order_in_postgresql Fix `relation.exists?` with giving `distinct`, `offset` and `order` for joined table
| * | Fix `relation.exists?` with giving `distinct`, `offset` and `order` for ↵Takayuki Nakata2019-07-101-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | joined table The error happens in PostgreSQL when using `relation.exists?` with `distinct`, `offset` and `order` for joined table. However, the error does not happen if either `distinct` or `offset` is removed. This behavior is confusing. Fixes #36632
* | Do not use aliases in GROUP BY clauseRyuta Kamizono2019-07-081-1/+1
| | | | | | | | | | | | | | It appears that Oracle does not allow using aliases in GROUP BY clause unlike ORDER BY clause. Fixes #36613.
* | PostgreSQL: Fix GROUP BY with ORDER BY virtual count attributeRyuta Kamizono2019-06-171-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | GROUP BY with virtual count attribute is invalid for almost all databases, but it is valid for PostgreSQL, and it had worked until Rails 5.2.2, so it is a regression for Rails 5.2.3 (caused by 311f001). I can't find perfectly solution for fixing this for now, but I would not like to break existing apps, so I decided to allow referencing virtual count attribute in ORDER BY clause when GROUP BY aggrigation (it partly revert the effect of 311f001) to fix the regression #36022. Fixes #36022.
* | Enable `Layout/EmptyLinesAroundAccessModifier` copRyuta Kamizono2019-06-136-7/+0
| | | | | | | | | | | | | | | | | | | | | | We sometimes say "✂️ newline after `private`" in a code review (e.g. https://github.com/rails/rails/pull/18546#discussion_r23188776, https://github.com/rails/rails/pull/34832#discussion_r244847195). Now `Layout/EmptyLinesAroundAccessModifier` cop have new enforced style `EnforcedStyle: only_before` (https://github.com/rubocop-hq/rubocop/pull/7059). That cop and enforced style will reduce the our code review cost.
* | Refactor `disallow_raw_sql!` to avoid `split(/\s*,\s*/)` to order argsRyuta Kamizono2019-06-091-0/+1
| | | | | | | | | | `split(/\s*,\s*/)` to order args and then `permit.match?` one by one is much slower than `permit.match?` once.
* | Allow quoted identifier string as safe SQL stringRyuta Kamizono2019-06-061-1/+1
|/ | | | | | | | | | | | | Currently `posts.title` is regarded as a safe SQL string, but `"posts"."title"` (it is a result of `quote_table_name("posts.title")`) is regarded as an unsafe SQL string even though a result of `quote_table_name` should obviously be regarded as a safe SQL string, since the column name matcher doesn't respect quotation, it is a little annoying. This changes the column name matcher to allow quoted identifiers as safe SQL string, now all results of the `quote_table_name` are regarded as safe SQL string.
* Implicit through table joins should be appeared before user supplied joinsRyuta Kamizono2019-05-191-17/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #36293 was an issue for through association with `joins` for a long time, but since #35864 through association with `left_joins` would also be affected by the issue. Implicit through table joins should be appeared before user supplied joins, otherwise loading through association with joins will cause a statement invalid error. Fixes #36293. ``` % ARCONN=postgresql bundle exec ruby -w -Itest test/cases/associations/has_many_through_associations_test .rb -n test_through_association_with_joins Using postgresql Run options: -n test_through_association_with_joins --seed 7116 # Running: E Error: HasManyThroughAssociationsTest#test_through_association_with_joins: ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: missing FROM-clause entry for table "posts" LINE 1: ... "comments_posts" ON "comments_posts"."post_id" = "posts"."i... ^ : SELECT "comments".* FROM "comments" INNER JOIN "comments" "comments_posts" ON "comments_posts"."post_id" = "posts"."id" INNER JOIN "posts" ON "comments"."post_id" = "posts"."id" WHERE "posts"."author_id" = $1 rails test test/cases/associations/has_many_through_associations_test.rb:61 Finished in 0.388657s, 2.5730 runs/s, 0.0000 assertions/s. 1 runs, 0 assertions, 0 failures, 1 errors, 0 skips ```
* Fix merging left_joins to maintain its own `join_type` contextRyuta Kamizono2019-04-273-8/+14
| | | | | | | | | | | | | | | This fixes a regression for #35864. Usually, stashed joins (mainly eager loading) are performed as LEFT JOINs. But the case of merging joins/left_joins of different class, that (stashed) joins are performed as the same `join_type` as the parent context for now. Since #35864, both (joins/left_joins) stashed joins might be contained in `joins_values`, so each stashed joins should maintain its own `join_type` context. Fixes #36103.
* Avoid redundant `attribute_alias?` before `attribute_alias`Ryuta Kamizono2019-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we want to get alias resolved attribute finally, we can use `attribute_alias` directly. For that purpose, avoiding redundant `attribute_alias?` makes alias attribute access 40% faster. https://gist.github.com/kamipo/e427f080a27b46f50bc508fae3612a0e Before (2c0729d8): ``` Warming up -------------------------------------- user['id'] 102.668k i/100ms user['new_id'] 80.660k i/100ms user['name'] 99.368k i/100ms user['new_name'] 81.626k i/100ms Calculating ------------------------------------- user['id'] 1.431M (± 4.0%) i/s - 7.187M in 5.031985s user['new_id'] 1.042M (± 4.2%) i/s - 5.243M in 5.039858s user['name'] 1.406M (± 5.6%) i/s - 7.055M in 5.036743s user['new_name'] 1.074M (± 3.6%) i/s - 5.387M in 5.024152s ``` After (this change): ``` Warming up -------------------------------------- user['id'] 109.775k i/100ms user['new_id'] 103.303k i/100ms user['name'] 105.988k i/100ms user['new_name'] 99.618k i/100ms Calculating ------------------------------------- user['id'] 1.520M (± 6.7%) i/s - 7.574M in 5.011496s user['new_id'] 1.485M (± 6.2%) i/s - 7.438M in 5.036252s user['name'] 1.538M (± 5.4%) i/s - 7.737M in 5.049765s user['new_name'] 1.516M (± 4.6%) i/s - 7.571M in 5.007293s ```
* Merge pull request #36029 from kamipo/deprecate_where_notRyuta Kamizono2019-04-232-9/+26
|\ | | | | Deprecate `where.not` working as NOR and will be changed to NAND in Rails 6.1
| * Deprecate `where.not` working as NOR and will be changed to NAND in Rails 6.1Ryuta Kamizono2019-04-192-9/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `where.not` with polymorphic association is partly fixed incidentally at 213796f (refer #33493, #26207, #17010, #16983, #14161), and I've added test case e9ba12f to avoid lose that fix accidentally in the future. In Rails 5.2, `where.not(polymorphic: object)` works as expected as NAND, but `where.not(polymorphic_type: object.class.polymorphic_name, polymorphic_id: object.id)` still unexpectedly works as NOR. To will make `where.not` working desiredly as NAND in Rails 6.1, this deprecates `where.not` working as NOR. If people want to continue NOR conditions, we'd encourage to them to `where.not` each conditions manually. ```ruby all = [treasures(:diamond), treasures(:sapphire), cars(:honda), treasures(:sapphire)] assert_equal all, PriceEstimate.all.map(&:estimate_of) ``` In Rails 6.0: ```ruby sapphire = treasures(:sapphire) nor = all.reject { |e| e.estimate_of_type == sapphire.class.polymorphic_name }.reject { |e| e.estimate_of_id == sapphire.id } assert_equal [cars(:honda)], nor without_sapphire = PriceEstimate.where.not( estimate_of_type: sapphire.class.polymorphic_name, estimate_of_id: sapphire.id ) assert_equal nor, without_sapphire.map(&:estimate_of) ``` In Rails 6.1: ```ruby sapphire = treasures(:sapphire) nand = all - [sapphire] assert_equal [treasures(:diamond), cars(:honda)], nand without_sapphire = PriceEstimate.where.not( estimate_of_type: sapphire.class.polymorphic_name, estimate_of_id: sapphire.id ) assert_equal nand, without_sapphire.map(&:estimate_of) ``` Resolves #31209.
* | Don't table name qualify aggrigate column for virtual attributeRyuta Kamizono2019-04-221-4/+2
| | | | | | | | Related 0ee96d13de29680e148ccb8e5b68025f29fd091c.
* | Remove useless `set_value` / `get_value` helper methodsRyuta Kamizono2019-04-221-15/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those helper methods makes relation values access 15% slower. https://gist.github.com/kamipo/e64439f7a206e1c5b5c69d92d982828e Before (02b5b8cb): ``` Warming up -------------------------------------- #limit_value 237.074k i/100ms #limit_value = 1 222.052k i/100ms Calculating ------------------------------------- #limit_value 6.477M (± 2.9%) i/s - 32.479M in 5.019475s #limit_value = 1 5.297M (± 4.3%) i/s - 26.424M in 4.999933s ``` After (this change): ``` Warming up -------------------------------------- #limit_value 261.109k i/100ms #limit_value = 1 239.646k i/100ms Calculating ------------------------------------- #limit_value 7.412M (± 1.6%) i/s - 37.077M in 5.003345s #limit_value = 1 6.134M (± 1.0%) i/s - 30.675M in 5.000908s ```
* | Give GeneratedRelationMethods module a nameRyuta Kamizono2019-04-191-1/+4
|/ | | | This follows #35595.
* Clarify exists check in logsDan Fitch2019-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default log messages for Model.exists?, when called from .save on an object which uses scoped uniqueness validation like: class Example < ApplicationRecord validates :field, uniqueness: {scope: parent_id} end can result in slightly misleading logs. An example case: ↳ app/controllers/example_controller.rb:23 (0.2ms) begin transaction ↳ app/controllers/example_controller.rb:39 Example Exists (0.2ms) SELECT 1 AS one FROM "examples" WHERE "examples"."field" IS NULL AND "examples"."parent_id" = ? LIMIT ? [["parent_id", 123], ["LIMIT", 1]] ↳ app/controllers/example_controller.rb:39 (0.1ms) rollback transaction To me, a Rails newbie, this parsed as the following: - started the transaction to create a thing - found that your object exists already! - so we rolled back the transaction (even though the actual cause of the transaction is something that happens after the Exists check.) All this does is add a question mark to the message, to make it clear in the log that this is a check, not a confirmation. This may be kind of silly, but it may save some future goofs by newbs like me.
* Remove duplicated attribute alias resolution in `_select!`Ryuta Kamizono2019-04-091-6/+3
| | | | This is also resolved in `arel_column`.
* Fix GROUP BY with calculate longer name field to respect `table_alias_length`Ryuta Kamizono2019-04-081-5/+6
| | | | Follow up of c9e4c848eeeb8999b778fa1ae52185ca5537fffe.
* Don't repeat same expression in SELECT and GROUP BY clausesRyuta Kamizono2019-04-061-26/+20
| | | | | | | | | | | | | | | | | | | | | This refactors `execute_grouped_calculation` and slightly changes generated GROUP BY queries, since I'd not prefer to repeat same expression in SELECT and GROUP BY clauses. Before: ``` SELECT COUNT(*) AS count_all, "topics"."author_name" AS topics_author_name, COALESCE(type, title) AS coalesce_type_title FROM "topics" GROUP BY "topics"."author_name", COALESCE(type, title) ``` After: ``` SELECT COUNT(*) AS count_all, "topics"."author_name" AS topics_author_name, COALESCE(type, title) AS coalesce_type_title FROM "topics" GROUP BY topics_author_name, coalesce_type_title ``` Although we generally don't guarantee to support Arel node constructed by user itself, this also fixes #24207.
* Stash `left_joins` into `joins` to deduplicate redundant LEFT JOINRyuta Kamizono2019-04-053-30/+30
| | | | | | | | | | | | | | | | | | | | | | | | | Originally the `JoinDependency` has the deduplication for eager loading (LEFT JOIN). This re-uses that deduplication for `left_joins`. And also, This makes left join order into part of joins, i.e.: Before: ``` association joins -> stash joins (eager loading, etc) -> string joins -> left joins ``` After: ``` association joins -> stash joins (eager loading, left joins, etc) -> string joins ``` Now string joins are able to refer left joins. Fixes #34325. Fixes #34332. Fixes #34536.
* Fix `count(:all)` with eager loading and explicit select and orderRyuta Kamizono2019-04-041-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This follows up ebc09ed9ad9a04338138739226a1a92c7a2707ee. We've still experienced a regression for `size` (`count(:all)`) with eager loading and explicit select and order when upgrading Rails to 5.1. In that case, the eager loading enforces `distinct` to subselect but still keep the custom select, it would cause the ORDER BY with DISTINCT issue. ``` % ARCONN=postgresql bundle exec ruby -w -Itest test/cases/relations_test.rb -n test_size_with_eager_loading_and_custom_select_and_order Using postgresql Run options: -n test_size_with_eager_loading_and_custom_select_and_order --seed 8356 # Running: E Error: RelationTest#test_size_with_eager_loading_and_custom_select_and_order: ActiveRecord::StatementInvalid: PG::InvalidColumnReference: ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list LINE 1: ..." ON "comments"."post_id" = "posts"."id" ORDER BY comments.i... ^ ``` As another problem on `distinct` is enforced, the result of `count` becomes fewer than expected if `select` is given explicitly. e.g. ```ruby Post.select(:type).count # => 11 Post.select(:type).distinct.count # => 3 ``` As long as `distinct` is enforced, we need to care to keep the result of `count`. This fixes both the `count` with eager loading problems.
* Optimizer hints should be applied on Top level query as much as possibleRyuta Kamizono2019-04-042-3/+13
| | | | | I've experienced this issue in our app, some hints only works on Top level query (e.g. `MAX_EXECUTION_TIME`).
* Merge pull request #35727 from zinosama/zzz/update-doc-for-includesRyuta Kamizono2019-04-011-1/+7
|\ | | | | | | | | | | Update API doc for #includes on unnecessary #references [ci skip]
| * [ci skip] Update doc for unnecessary #referenceszino2019-03-231-1/+7
| | | | | | | | Update doc for #includes to clarify that #references is unnecessary when conditions are passed into #includes as a hash.
* | Add `ActiveRecord::Relation#extract_associated` for extracting associated ↵David Heinemeier Hansson2019-03-291-0/+13
|/ | | | | record (#35784) * Add `ActiveRecord::Relation#extract_associated` for extracting associated records from a relation
* Add Relation#annotate for SQL commentingMatt Yoho2019-03-211-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has two main portions: 1. Add SQL comment support to Arel via Arel::Nodes::Comment. 2. Implement a Relation#annotate method on top of that. == Adding SQL comment support Adds a new Arel::Nodes::Comment node that represents an optional SQL comment and teachers the relevant visitors how to handle it. Comment nodes may be added to the basic CRUD statement nodes and set through any of the four (Select|Insert|Update|Delete)Manager objects. For example: manager = Arel::UpdateManager.new manager.table table manager.comment("annotation") manager.to_sql # UPDATE "users" /* annotation */ This new node type will be used by ActiveRecord::Relation to enable query annotation via SQL comments. == Implementing the Relation#annotate method Implements `ActiveRecord::Relation#annotate`, which accepts a comment string that will be appeneded to any queries generated by the relation. Some examples: relation = Post.where(id: 123).annotate("metadata string") relation.first # SELECT "posts".* FROM "posts" WHERE "posts"."id" = 123 # LIMIT 1 /* metadata string */ class Tag < ActiveRecord::Base scope :foo_annotated, -> { annotate("foo") } end Tag.foo_annotated.annotate("bar").first # SELECT "tags".* FROM "tags" LIMIT 1 /* foo */ /* bar */ Also wires up the plumbing so this works with `#update_all` and `#delete_all` as well. This feature is useful for instrumentation and general analysis of queries generated at runtime.
* Add test case for unscoping `:optimizer_hints`Ryuta Kamizono2019-03-181-1/+1
|
* Support Optimizer HintsRyuta Kamizono2019-03-161-0/+24
| | | | | | | | | | | | | | | | | | We as Arm Treasure Data are using Optimizer Hints with a monkey patch (https://gist.github.com/kamipo/4c8539f0ce4acf85075cf5a6b0d9712e), especially in order to use `MAX_EXECUTION_TIME` (refer #31129). Example: ```ruby class Job < ApplicationRecord default_scope { optimizer_hints("MAX_EXECUTION_TIME(50000) NO_INDEX_MERGE(jobs)") } end ``` Optimizer Hints is supported not only for MySQL but also for most databases (PostgreSQL on RDS, Oracle, SQL Server, etc), it is really helpful to turn heavy queries for large scale applications.
* 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.