| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
When one relation is merged into another that has a different base class
merging `from_clause` causes invalid SQL to be generated
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `Relation::Merger` has a problem that order values would be merged
as nested array.
That was caused an issue #33664 since if array value is passed to
`order` and first element in the array includes `?`, the array is
regarded as a prepared statement and bind variables.
https://api.rubyonrails.org/classes/ActiveRecord/Sanitization/ClassMethods.html#method-i-sanitize_sql_for_order
Just merging that as splat args like other values would fix the issue.
Fixes #33664.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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?
|
| | |
|
| |
|
|
|
|
|
| |
`joins_values.partition` will break joins values order. It should be
kept as user intended order.
Fixes #15488.
|
| |
|
|
|
| |
This is preparation to respect parent relation's alias tracking for
fixing #30681.
|
| |
|
|
|
|
|
|
|
| |
Currently `Relation#merge` will almost fill `values` with empty values
(e.g. `other.order_values` is always true, it should be
`other.order_values.any?`). This means that `Relation#merge` always
changes `values` even if actually `values` is nothing changed. This
behavior will makes `Relation#empty_scope?` fragile. So `Relation#merge`
should avoid unnecessary changes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this fix, `JoinDependency` doesn't use a custom table alias:
```
% ARCONN=sqlite3 be ruby -w -Itest test/cases/relations_test.rb -n test_using_a_custom_table_with_joins_affects_the_wheres
Using sqlite3
Run options: -n test_using_a_custom_table_with_joins_affects_the_wheres --seed 14531
E
Error:RelationTest#test_using_a_custom_table_with_joins_affects_the_wheres:
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: posts.author_id: SELECT "omg_posts".* FROM "posts" "omg_posts" INNER JOIN "authors" ON "authors"."id" = "posts"."author_id" WHERE "omg_posts"."title" = ? LIMIT ?
```
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Introduced low level methods #set_value and #get_value for setting query attributes:
relation.set_value(:where, {id: 1})
relation.get_value(:includes)
Used those internally when working with relation's attributes
at the abstract level
|
| | |
|
| |
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
|
|
|
| |
The code that set the from clause was removed in
bdc5141652770fd227455681cde1f9899f55b0b9. I did not give any reason for
doing so. My assumption was that I intended to change it to use the
clause objects, but forgot. We appeared to not have test coverage for
this case.
Fixes #22996
|
| |
|
|
|
|
| |
Since the strings are dynamically computed from a constant, the actual
strings we're creating are a known set. We can compute them ahead of
time, and reduce the number of allocations in that method.
|
| |
|
|
|
|
|
|
|
| |
When preload is used in a default scope the preload_values were
returning nested arrays and causing the preloader to fail because it
doesn't know how to deal with nested arrays. So before calling preload!
we need to splat the arguments.
This is not needed to includes because it flatten its arguments.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Couldn't find other way to get the association name from a given class
other than looping through `reflect_on_all_associations` reflections ..
Noticed this one while looking at this example:
```ruby
class Product < ActiveRecord::Base
has_many :variants
has_many :translations
end
class Translation < ActiveRecord::Base
belongs_to :product
end
class Variant < ActiveRecord::Base
belongs_to :product
end
class BugTest < Minitest::Test
def test_merge_stuff
product = Product.create! name: 'huhu'
variant = Variant.create! product_id: product.id
Translation.create! locale: 'en', product_id: product.id
product_relation = Product.all
.preload(:translations)
.joins(:translations)
.merge(Translation.where(locale: 'en'))
.where(name: 'huhu')
assert_equal variant, Variant.joins(:product).merge(product_relation).first
end
end
```
|
| | |
|
| |
|
|
|
|
|
| |
Contrary to my previous commit message, it wasn't overkill, and led to
much cleaner code.
[Sean Griffin & anthonynavarre]
|
| |
|
|
|
|
|
|
|
|
| |
The last place that was assigning it was when `from` is called with a
relation to use as a subquery. The implementation was actually
completely broken, and would break if you called `from` more than once,
or if you called it on a relation, which also had its own join clause,
as the bind values would get completely scrambled. The simplest solution
was to just move it into its own array, since creating a `FromClause`
class for this would be overkill.
|
| |
|
|
| |
This will make it easy to add `having_clause` and `join_clause` later.
|
| |
|
|
|
|
| |
This object being a black box, it knows the details of how to merge
itself with another where clause. This removes all references to where
values or bind values in `Relation::Merger`
|
| | |
|
| |
|
|
|
|
|
| |
Construction of relations can be a hotspot, we don't want to create one
of these in the constructor. This also allows us to do more expensive
things in the predicate builder's constructor, since it's created once
per AR::Base subclass
|
| |
|
|
| |
Oh hey, we got to remove some code because of that!
|
| |
|
|
| |
The value methods will default to an empty array for us automatically
|
| |
|
|
|
|
|
|
| |
The change to accessing keys directly was originally added to allow
`merge` to take a hash. The implementation of `HashMerger` no longer
requires us to be doing so. Accessing the values directly makes it
impossible to change internal storage details, even if shim methods are
added temporarily
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ActiveRecord::Relation::Merger's filter_binds method does not filter out bind
variables when one of the attribute nodes has a string name, but the other has
a symbol name, even when those names are actually equal.
This can result in there being more bind variables than placeholders in the
generated SQL. This is particularly an issue for PostgreSQL, where this is
treated as an error.
This patch changes the filter_binds method to make it convert both attribute
names to strings before comparing.
|
| |
|
|
|
|
|
|
| |
Fixes #14752
Select mimics the block interface of arrays, but does not mock the
block interface for select!. This change moves the api to be a
private method, _select!.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reverse_order method was using a flag to control if the order should
be reversed or not. Instead of using this variable just build the reverse order
inside its proper method.
This implementation was leading to an unexpected behavior when using
reverse_order and then applying reorder(nil).
Example:
Before
Post.order(:name).reverse_order.reorder(nil)
# => SELECT "posts".* FROM "posts" ORDER BY "posts"."id" DESC
After
Post.order(:name).reverse_order.reorder(nil)
# => SELECT "posts".* FROM "posts"
|
| | |
|
| |
|
|
| |
The original code ignores the `false` value because `false.blank? # => true`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous implementation was necessary in order to support stuff
like:
class Post < ActiveRecord::Base
default_scope where(published: true)
scope :ordered, order("created_at")
end
If we didn't evaluate the default scope at the last possible moment
before sending the SQL to the database, it would become impossible to
do:
Post.unscoped.ordered
This is because the default scope would already be bound up in the
"ordered" scope, and therefore wouldn't be removed by the
"Post.unscoped" part.
In 4.0, we have deprecated all "eager" forms of scopes. So now you must
write:
class Post < ActiveRecord::Base
default_scope { where(published: true) }
scope :ordered, -> { order("created_at") }
end
This prevents the default scope getting bound up inside the "ordered"
scope, which means we can now have a simpler/better/more natural
implementation of default scoping.
A knock on effect is that some things that didn't work properly now do.
For example it was previously impossible to use #except to remove a part
of the default scope, since the default scope was evaluated after the
call to #except.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
