- 07 8月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
Directly `klass.new` is clear enough than factory methods.
-
- 19 7月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
In Active Record internal, `arel_table` is not directly used but `arel_attribute` is used, since `arel_table` doesn't normalize an attribute name as a string, and doesn't resolve attribute aliases. For the above reason, `arel_attribute` should be used rather than `arel_table`, but most people directly use `arel_table`, both `arel_table` and `arel_attribute` are private API though. Although I'd not recommend using private API, `arel_table` is actually widely used, and it is also problematic for unscopeable queries and hash-like relation merging friendly, as I explained at #39863. To resolve the issue, this change moves Arel attribute normalization (attribute name as a string, and attribute alias resolution) into `arel_table`.
-
- 14 7月, 2020 1 次提交
-
-
由 Phil Coggins 提交于
-
- 06 7月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
`PredicateBuilder.references` and `PredicateBuilder#build_from_hash` does similar processing and both requires stringify keys for passed hash argument. This consolidates stringify keys to avoid extra string allocation in `PredicateBuilder`.
-
- 21 6月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
I'd not prefer to allocate its less interested object, it doesn't improve readability, and make code slower.
-
- 20 6月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
It is no longer only for `or` but also for `and`.
-
- 15 6月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
I often hit the inconvenience (recently in #39558). `and`/`or` are focused to combine where-like clauses, so we often use one-time relation which has only where clause. But if the receiver has values other than where clause (e.g. `order`, `select`, `includes`, etc), `and`/`or` will raise structurally incompatible error. Since it is harder to predict the receiver has which values other than where clause before doing `and`/`or`, that restriction is a little annoying to me. So I'd like to relax that restriction, at least unless other values are set explicitly for multiple values.
-
- 07 6月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
As described at #39328, `relation.merge` behaves inspired as Hash-like merge for where clause. In other words, currently there is no official way to intersect the result by both relation conditions (i.e. there is no official way to maintain both relation conditions). To resolve that issue, I'd like to support a way to intersect relations as `relation.and`. ```ruby david_and_mary = Author.where(id: [david, mary]) mary_and_bob = Author.where(id: [mary, bob]) # => [bob] david_and_mary.merge(mary_and_bob) # => [mary, bob] david_and_mary.and(mary_and_bob) # => [mary] david_and_mary.or(mary_and_bob) # => [david, mary, bob] ``` Fixes #39232.
-
- 29 5月, 2020 2 次提交
-
-
由 Ryuta Kamizono 提交于
Related to #39292. Fixes #39460.
-
由 Ryuta Kamizono 提交于
-
- 27 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
Follow up to #39415.
-
- 24 5月, 2020 4 次提交
-
-
由 sinsoku 提交于
An error occurs when you pass a relation with SQL comments to the `or` method. ```ruby class Post scope :active, -> { where(active: true).annotate("active posts") } end Post.where("created_at > ?", Time.current.beginning_of_month) .or(Post.active) ``` In order to work without `ArgumentError`, it changes the `or` method to ignore SQL comments in the argument. Ref: https://github.com/rails/rails/pull/38145#discussion_r363024376
-
由 Ryuta Kamizono 提交于
ff45b9e9 had removed that limitation for `or`. [ci skip]
-
由 Ryuta Kamizono 提交于
`joins_values` is already `compact_blank!`ed, so `blank?` check is entirely redundant.
-
由 Ryuta Kamizono 提交于
We've learned that `merge` causes duplicated multiple values easily, so if we missed to deduplicate the values, it will cause weird behavior like #38052, #39171. I've investigated the deduplication for the values, at least that had existed since Rails 3.0. https://github.com/rails/rails/commit/bed9179aa1496f6d28891cf515af0d7e515ebbab Aggregations with group by multiple fields was introduced at Rails 3.1, but we missed the deduplication for the aggregation result, unlike the generated SQL. https://github.com/rails/rails/commit/a5cdf0b9eb860c4370ae5fde231e1b61f71b6b65 While the investigation, I've found that `annotate` is also missed the deduplication. I don't suppose this weird behavior is intended for both. So I'd like to deprecate the duplicated behavior in Rails 6.1, and will be deduplicated all multiple values in Rails 6.2. To migrate to Rails 6.2's behavior, use `uniq!(:group)` to deduplicate group fields. ```ruby accounts = Account.group(:firm_id) # duplicated group fields, deprecated. accounts.merge(accounts.where.not(credit_limit: nil)).sum(:credit_limit) # => { # [1, 1] => 50, # [2, 2] => 60 # } # use `uniq!(:group)` to deduplicate group fields. accounts.merge(accounts.where.not(credit_limit: nil)).uniq!(:group).sum(:credit_limit) # => { # 1 => 50, # 2 => 60 # } ```
-
- 20 5月, 2020 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
- 19 5月, 2020 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
Currently the query values normalization for multiple values is missing some parts. Some values are flatten, but others are not flatten. Some values are compact, but others are not compact. some values are compact_blank, but others are not compact_blank. Originally all multiple values should be flatten and compact_blank before `build_arel`, if it is not ensured which multiple values are normalized or not, we need to normalize it again carefully and conservatively in `build_arel`. To unify the query values normalization for multiple values, ensure the normalization in `check_if_method_has_arguments!` since all multiple values should be checked by the method.
-
- 18 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
Related #39236. `relation.merge` method sometimes replaces mergee side condition, but sometimes maintain both conditions unless `relation.rewhere` is used. It is very hard to predict merging result whether mergee side condition will be replaced or not. One existing way is to use `relation.rewhere` for merger side relation, but it is also hard to predict a relation will be used for `merge` in advance, except one-time relation for `merge`. To address that issue, I propose to support merging option `:rewhere`, to allow mergee side condition to be replaced exactly. That option will allow non-`rewhere` relation behaves as `rewhere`d relation. ```ruby david_and_mary = Author.where(id: david.id..mary.id) # both conflict conditions exists david_and_mary.merge(Author.where(id: bob)) # => [] # mergee side condition is replaced by rewhere david_and_mary.merge(Author.rewhere(id: bob)) # => [bob] # mergee side condition is replaced by rewhere option david_and_mary.merge(Author.where(id: bob), rewhere: true) # => [bob] ```
-
- 17 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 16 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
#38354 is caused by #36304, to fix invalid joins order for through associations. Actually passing Arel joins to `joins` is not officially supported unlike string joins, and also Arel joins could be easily converted to string joins by `to_sql`. But I'd not intend to break existing apps without deprecation cycle, so I've changed to mark only implicit joins as leading joins, to maintain the original joins order for user supplied Arel joins. Fixes #38354.
-
- 13 5月, 2020 4 次提交
-
-
由 Ryuta Kamizono 提交于
#38597 is caused by #35864. To reproduce this issue, at least it is required four different models and three left joins from different relations. When merging a relation from different model, new stashed (left) joins should be placed before existing stashed joins, but #35864 had broken that expectation if left joins are stashed multiple times. This fixes that stashed left joins order as expected. Fixes #38597.
-
由 Ryuta Kamizono 提交于
That issues are caused by using only the model's cast types on the relation. To fix that issues, use the attribute's type caster takes precedence over the model's cast types on the relation. Fixes #35232. Fixes #36042. Fixes #37484.
-
由 Ryuta Kamizono 提交于
Association look up requires association class is loaded especially for through association. Just apply that look up only in aggregation column for now.
-
由 Ryuta Kamizono 提交于
Follow up of #39255. Previously aggregation functions only use the model's attribute types on the relation for type cast, this will be looking up association's attribute and type caster if a column name is table name qualified. Fixes #39248.
-
- 10 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 07 5月, 2020 2 次提交
-
-
由 Ryuta Kamizono 提交于
Actually that result is odd and hard to predictable result to me, but we should not change the public behavior without deprecation cycle. I had not intended to break any apps, so I've restored the behavior. Fixes #39171.
-
由 Ryuta Kamizono 提交于
It is possible to unscope only the column in the specified table. ```ruby posts = Post.joins(:comments).group(:"posts.hidden") posts = posts.where("posts.hidden": false, "comments.hidden": false) posts.count # => { false => 10 } # unscope both hidden columns posts.unscope(where: :hidden).count # => { false => 11, true => 1 } # unscope only comments.hidden column posts.unscope(where: :"comments.hidden").count # => { false => 11 } ``` Co-authored-by: NSlava Korolev <korolvs@gmail.com>
-
- 05 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
```ruby steve = Person.find_by(name: "Steve") david = Author.find_by(name: "David") relation = Essay.where(writer: steve) # Before relation.rewhere(writer: david).to_a # => [] # After relation.rewhere(writer: david).to_a # => [david] ``` For now `rewhere` only works for truly column names, doesn't work for alias attributes, nested conditions, associations. To fix that, need to build new where clause first, and then get attribute names from new where clause.
-
- 03 5月, 2020 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 23 4月, 2020 1 次提交
-
-
由 Godfrey Chan 提交于
I wrote this shell script to find words from the Rails repo, so I can paste them into https://www.horsepaste.com/ for the [codenames game](https://en.m.wikipedia.org/wiki/Codenames_(board_game)). ```bash git grep -Il '' | \ grep -v -E "CHANGELOG|Gemfile|gemspec|package\.json|yarn\.lock" | \ xargs cat | \ sed '/[^ ]\{10,\}/d' | \ sed 's/\([A-Z]\)/ \1/g' | \ tr 'A-Z' 'a-z' | \ tr -c -s 'a-z' '\n' | \ sed '/^.\{0,3\}$/d' | \ sort | \ uniq | \ tr '\n' ',' | \ pbcopy ``` You can see the result in https://www.horsepaste.com/rails-fixed. Click "Next game" to cycle the words. Found some typos in the codebase from this
😂 This is how I generated the list of possible typos: ```bash git grep -Il '' | \ grep -v -E "CHANGELOG|Gemfile|gemspec|package\.json|yarn\.lock" | \ xargs cat | \ sed '/[^ ]\{10,\}/d' | \ sed 's/\([A-Z]\)/ \1/g' | \ tr 'A-Z' 'a-z' | \ tr -c -s 'a-z' '\n' | \ sed '/^.\{0,3\}$/d' | \ sort | \ uniq | \ aspell --ignore-case list ``` I manually reviewed the list and made the corrections in this commit. The rest on the list are either: * Bugs in my script: it split things like "doesn't" into "doesn" and "t", if find things like `#ffffff` and extracts "ffffff" as a word, etc * British spelling: honour, optimised * Foreign words: bonjour, espanol * Names: nginx, hanekawa * Technical words: mutex, xhtml * Portmanteau words: autosave, nodelist * Invented words: camelize, coachee * Shortened words: attrs, repo * Deliberate typos: hllo, hillo (used in code examples, etc) * Lorem ipsum words: arcu, euismod This is the [output](https://gist.github.com/chancancode/eb0b573d667dc31906f33f1fb0b22313) of the script *after* fixing the typos included in this commit. In theory, someone can run that command again in the future and compare the output to catch new typos (i.e. using my list to filter out known typos). Limitations: the aspell dictionary could be wrong, I could have miss things, and my script ignores words that are less than 3 characters or longer than 10 characters.
-
- 05 3月, 2020 1 次提交
-
-
由 Yash Ladha 提交于
This is done because concerns of respective steps can be separated, which in turns leads to easier walkthrough and verbosity. Also stretching a function to large horizontal bounds doesn't looks good.
-
- 21 2月, 2020 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
Follow-up of ac9b11a8.
-
- 20 2月, 2020 1 次提交
-
-
由 eileencodes 提交于
Add `#strict_loading` to any record to prevent lazy loading of associations. `strict_loading` will cascade down from the parent record to all the associations to help you catch any places where you may want to use `preload` instead of lazy loading. This is useful for preventing N+1's. Co-authored-by: NAaron Patterson <aaron.patterson@gmail.com>
-
- 07 2月, 2020 1 次提交
-
-
由 Erik Berlin 提交于
-
- 29 1月, 2020 1 次提交
-
-
由 Larry Reid 提交于
-
- 14 1月, 2020 2 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
由 Carlos Antonio da Silva 提交于
[ci skip]
-
- 11 1月, 2020 1 次提交
-
-
由 Tom Rossi 提交于
-