| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
the time
|
| | |
|
| |
|
|
| |
#join_associations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to fix #10421 I need to enable merge to take an option
so that relations could be merged without making the last where
condition to win.
That fix would forever reside in 4-0-stable branch and would not be
merged to master since using scope without lambda has been deprecated.
In this commit I have extracted code into a method and I think it
makes code look better. Hence the request to merge it in both
master and 4-0-stable.
If there is any concern then this code can be merged only in
4-0-stable and that would be fine too.
|
| |
|
|
| |
warning: `*' interpreted as argument prefix
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #3002. Also see #5494.
```
class Comment < ActiveRecord::Base
belongs_to :post
end
class Author < ActiveRecord::Base
has_many :posts
end
class Post < ActiveRecord::Base
belongs_to :author
has_many :comments
end
```
`Comment.joins(:post).merge(Post.joins(:author).merge(Author.where(:name => "Joe Blogs"))).all` would
fail with `ActiveRecord::ConfigurationError: Association named 'author' was not found on Comment`.
It is failing because `all` is being called on relation which looks like this after all the merging:
`{:joins=>[:post, :author], :where=>[#<Arel::Nodes::Equality: ....}`. In this relation all the context that
`Post` was joined with `Author` is lost and hence the error that `author` was not found on `Comment`.
Ths solution is to build JoinAssociation when two relations with join information are being merged. And later
while building the arel use the previously built `JoinAssociation` record in `JoinDependency#graft` to
build the right from clause.
Thanks to Jared Armstrong (https://github.com/armstrjare) for most of the work. I ported it to make it
compatible with new code base.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.
In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.
The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:
default_scope.merge(association_scope)
If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')
Now, the RHS of the merge is left alone.
Fixes #8990
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
Calculating -------------------------------------
ar 87 i/100ms
-------------------------------------------------
ar 823.4 (±11.8%) i/s - 4089 in 5.070234s
After:
Calculating -------------------------------------
ar 88 i/100ms
-------------------------------------------------
ar 894.1 (±3.9%) i/s - 4488 in 5.028161s
Same test as 3a6dfca7f5f5bd45cea2f6ac348178e72423e1d5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
before:
Calculating -------------------------------------
ar 83 i/100ms
-------------------------------------------------
ar 832.1 (±4.0%) i/s - 4233 in 5.096611s
after:
Calculating -------------------------------------
ar 87 i/100ms
-------------------------------------------------
ar 839.0 (±9.3%) i/s - 4176 in 5.032782s
Benchmark:
require 'config/environment'
require 'benchmark/ips'
GC.disable
unless User.find_by_login('tater')
u = User.new
u.login = 'tater'
u.save!
end
def active_record
user = User.find_by_login('tater')
starred = user.starred_items.count
end
active_record
Benchmark.ips do |x|
x.report("ar") { active_record }
end
|
| |
|
|
|
|
| |
This is a real fix (as compared to the band-aid in b127d86c), which uses
the recently-added equality methods for ARel nodes. It has the side
benefit of simplifying the merge code a bit.
|
| |
|
|
|
|
|
|
|
| |
This is at best a band-aid for a more proper fix, since it won't truly
handle the removal of the previous equality condition of these other
nodes. I'm planning to put in some work on ARel toward supporting that
goal.
Related: rails/arel#130, ernie/squeel#153, ernie/squeel#156
|
| | |
|
| | |
|
| |
|
|
| |
Record.from("(#{sub_query.to_sql})") -> Record.from(sub_query)
Record.from("(#{sub_query.to_sql}) a") -> Record.from(sub_query, :a)
|
| |
|
|
|
|
|
| |
armstrjare/active_record_relation_keep_association_join_context_on_merge"
This reverts commit dcd04e76179611a9db28c9e391aa7d6c2a5b046a, reversing
changes made to 58a49875df63729f07a9a81d1ee349087d258df5.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
