- 13 6月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 27 4月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 10 4月, 2019 1 次提交
-
-
由 Dan Fitch 提交于
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.
-
- 05 4月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 07 3月, 2019 1 次提交
-
-
由 Samantha John 提交于
-
- 01 3月, 2019 1 次提交
-
-
由 Mehmet Emin INAC 提交于
-
- 28 2月, 2019 1 次提交
-
-
由 Mehmet Emin INAC 提交于
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.
-
- 08 2月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 18 1月, 2019 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 08 1月, 2019 1 次提交
-
-
由 Gannon McGibbon 提交于
Allow `ActionController::Params` as argument of `ActiveRecord::Base#exists?`
-
- 27 11月, 2018 1 次提交
-
-
由 Tekin Suleyman 提交于
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
-
- 27 10月, 2018 1 次提交
-
-
由 r7kamura 提交于
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!`.
-
- 23 9月, 2018 1 次提交
-
-
由 yuuji.yaginuma 提交于
In Ruby 2.3 or later, `String#+@` is available and `+@` is faster than `dup`. ```ruby # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |x| x.report('+@') { +"" } x.report('dup') { "".dup } x.compare! end ``` ``` $ ruby -v benchmark.rb ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] Warming up -------------------------------------- +@ 282.289k i/100ms dup 187.638k i/100ms Calculating ------------------------------------- +@ 6.775M (± 3.6%) i/s - 33.875M in 5.006253s dup 3.320M (± 2.2%) i/s - 16.700M in 5.032125s Comparison: +@: 6775299.3 i/s dup: 3320400.7 i/s - 2.04x slower ```
-
- 20 9月, 2018 1 次提交
-
-
由 Rafael Mendonça França 提交于
When you pass an empty array to find we know we shoudl return an empty array but it is surprising that we are returning the original empty array instead of a new one.
-
- 08 9月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 01 8月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
This reverts commit d162188d, reversing changes made to 35767828. Reason: #24131 conflicts the #5153's default order contract, it means that existing apps would be broken by that change. We don't want to break existing apps without a deprecation cycle.
-
- 20 7月, 2018 1 次提交
-
-
由 Brian Christian 提交于
-
- 03 7月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 19 6月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
Currently, column aliases which is used for eager loading are calculated before constructing all table aliases in FROM clause. `JoinDependency#join_constraints` constructs table aliases for `joins` first, and then always re-constructs table aliases for eager loading. If both `joins` and eager loading are given a same table association, the re-construction would cause the discrepancy between column aliases and table aliases. To avoid the discrepancy, the column aliases should be calculated after all table aliases are constructed. Fixes #30603.
-
- 07 6月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
If `eager_loading` is true, `apply_join_dependency` force applies LIMIT/OFFSET before JOINs by `limited_ids_for` to keep parent records count. But for aggregation queries, LIMIT/OFFSET should be applied after aggregations the same as SQL semantics. And also, we could not replace SELECT list by `limited_ids_for` when a query has a GROUP BY clause. It had never been worked since it will causes generating invalid SQL for MySQL, PostgreSQL, and probably most backends. ``` % ARCONN=postgresql be ruby -w -Itest test/cases/calculations_test.rb -n test_group_by_with_limit Using postgresql Run options: -n test_group_by_with_limit --seed 20925 # Running: E Error: CalculationsTest#test_group_by_with_limit: ActiveRecord::StatementInvalid: PG::GroupingError: ERROR: column "posts.id" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FRO... ^ : SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FROM "posts" LEFT OUTER JOIN "comments" ON "comments"."post_id" = "posts"."id" GROUP BY "posts"."type" ORDER BY "posts"."type" ASC LIMIT $1 ``` Fixes #8103. Closes #27249.
-
- 04 3月, 2018 1 次提交
-
-
由 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.
-
- 14 1月, 2018 1 次提交
-
-
由 Ryuta Kamizono 提交于
This is a complete fix to #30995. Originally alias tracker will only track table aliases on `Arel::Nodes::Join`, other args are ignored. Since c5ab6e51, parent aliases hash will be passed then it caused the regression #30995. It is enough to pass list of `Arel::Nodes::Join` simply, not need to pass garbage args which will be ignored.
-
- 11 1月, 2018 2 次提交
-
-
由 Ryuta Kamizono 提交于
`find_with_associations` is meaningless name in this point since it just contain `construct_join_dependency` and `apply_join_dependency`, does not contain finding anything. If `apply_join_dependency` returns `relation` and `join_dependency` then `find_with_associations` is no longer needed.
-
由 Ryuta Kamizono 提交于
`relation.exists?` just wants to know if there is a result or not, does not need the exact records matched. Therefore, an intermediate SELECT query for eager loading is not necessary.
-
- 10 1月, 2018 1 次提交
-
-
由 Brian Christian 提交于
-
- 07 1月, 2018 3 次提交
-
-
由 Ryuta Kamizono 提交于
We can use `relation.last(index)[-index]` instead of loading all records when using reversible order because `last` will call `reverse_order`.
-
由 Ryuta Kamizono 提交于
Currently `last` with `offset` behaves incorrectly because `offset` can not be reversed like `limit`. Therefore, `offset` should also be handled like `limit`.
-
由 Ryuta Kamizono 提交于
-
- 28 11月, 2017 1 次提交
-
-
- 26 11月, 2017 1 次提交
-
-
由 Nikita Misharin 提交于
-
- 14 11月, 2017 1 次提交
-
-
由 Nikolai B 提交于
Make it clear that `exists?` can be chained onto a relation
-
- 06 11月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
Fixes #30315.
-
- 09 10月, 2017 3 次提交
-
-
由 Ryuta Kamizono 提交于
I don't think this is a good abstraction because the internal method is used only if the relation need to be applied join dependency.
-
由 Ryuta Kamizono 提交于
`relation.exists?` should reference correct aliases while joining tables of has_many through associations.
-
由 Ryuta Kamizono 提交于
-
- 08 10月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
This is preparation to respect parent relation's alias tracking for fixing #30681.
-
- 14 9月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
Because `quoted_table_name` doesn't respect table alias. We should use `arel_attribute` for that, so I added `column_name_from_arel_node` to generate column name from an arel node.
-
- 25 8月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
This regression was caused by caa178c1. The block for `set_inverse_instance` should also be passed to join dependency. Fixes #30402.
-
- 29 7月, 2017 1 次提交
-
-
由 Gaurish Sharma 提交于
This builds on top of 15e2da65. now it also returns exact Ids which were not found which will be debugging simple.
-
- 24 7月, 2017 1 次提交
-
-
由 Sean Griffin 提交于
A common source of bugs and code bloat within Active Record has been the need for us to maintain the list of bind values separately from the AST they're associated with. This makes any sort of AST manipulation incredibly difficult, as any time we want to potentially insert or remove an AST node, we need to traverse the entire tree to find where the associated bind parameters are. With this change, the bind parameters now live on the AST directly. Active Record does not need to know or care about them until the final AST traversal for SQL construction. Rather than returning just the SQL, the Arel collector will now return both the SQL and the bind parameters. At this point the connection adapter will have all the values that it had before. A bit of this code is janky and something I'd like to refactor later. In particular, I don't like how we're handling associations in the predicate builder, the special casing of `StatementCache::Substitute` in `QueryAttribute`, or generally how we're handling bind value replacement in the statement cache when prepared statements are disabled. This also mostly reverts #26378, as it moved all the code into a location that I wanted to delete. /cc @metaskills @yahonda, this change will affect the adapters Fixes #29766. Fixes #29804. Fixes #26541. Close #28539. Close #24769. Close #26468. Close #26202. There are probably other issues/PRs that can be closed because of this commit, but that's all I could find on the first few pages.
-