| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This is no longer required now that we are injecting a type caster
object into the Arel table, with the exception of uniqueness
validations. Since it calls `ConnectionAdapter#type_cast`, the value has
already been cast for the database. We don't want Arel to attempt to
cast it further, so we need to continue wrapping it in a quoted node.
This can potentially go away when this validator is refactored to make
better use of `where` or the predicate builder.
|
| |
|
|
|
|
|
| |
Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have several test cases on "tricky" types that are essentially
testing that `update_all` goes through the same type casting behavior as
a normal assignment + save. We recently had another case to add this
test for another type in https://github.com/rails/rails/pull/12742.
Rather than testing this separately for every type which is "tricky"
when round tripping, let's instead have a fairly exhaustive test that
ensures we're getting the correct values at every step for `update_all`.
Given the structure of the code now, we can be confident that if the
type is correct, and `update_all` is type casting correctly, we're going
to get the right behavior for all types.
|
| |\
| |
| |
| |
| |
| |
| | |
Fix insertion of records for hmt association with scope
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
Outer joins were being built on the root relation klass rather than the
one specified in the join dependency root
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Deprecate the delegation of Array bang methods in ActiveRecord::Delegation
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/cases/relation_test.rb
|
| | |
| |
| |
| | |
cases/relation/mutation_test.
|
| | |
| |
| |
| | |
The original code ignores the `false` value because `false.blank? # => true`.
|
| |\ \
| |/
|/| |
Re-use order arguments pre-processing for reorder
|
| | |
| |
| |
| | |
be consistent.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Stop special-casing Arel::Nodes as exempt from reference scanning in
order. Instead, only scan order values that are strings for a table
reference.
|
| |
|
|
|
|
|
|
| |
fixes #10669
While joining_values special treatment is given to string values.
By flattening the array it ensures that string values are detected
as strings and not arrays.
|
| |\
| |
| | |
PostgreSQL specific test cleanup
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
Object#respond_to? returns singletons and thus we inherit that contract.
The implementation of the predicate is good, but the test is only
checking boolean semantics, which in this case is not enough.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #4208
If a query selects only a few columns and gives custom names to
those columns then respond_to? was returning true for the non
selected columns. However calling those non selected columns
raises exception.
post = Post.select("'title' as post_title").first
In the above case when `post.body` is invoked then an exception is
raised since `body` attribute is not selected. Howevere `respond_to?`
did not behave correctly.
pos.respond_to?(:body) #=> true
Reason was that Active Record calls `super` to pass the call to
Active Model and all the columns are defined on Active Model.
Fix is to actually check if the data returned from the db contains
the data for column in question.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.
There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #9275.
When `#order` is called with a Symbol this patch will prepend the quoted_table_name.
Before the postgresql adapter failed to build queries containg a join and an order
with a symbol.
This expansion happens for all adapters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present, ActiveRecord::Delegation compiles delegation methods on a
global basis. The compiled methods apply to all subsequent Relation
instances. This creates several problems:
1) After Post.all.recent has been called, User.all.respond_to?(:recent)
will be true, even if User.all.recent will actually raise an error due
to no User.recent method existing. (See #8080.)
2) Depending on the AR class, the delegation should do different things.
For example, if a Post.zip method exists, then Post.all.zip should call
it. But this will then result in User.zip being called by a subsequent
User.all.zip, even if User.zip does not exist, when in fact
User.all.zip should call User.all.to_a.zip. (There are various
variants of this problem.)
We are creating these compiled delegations in order to avoid method
missing and to avoid repeating logic on each invocation.
One way of handling these issues is to add additional checks in various
places to ensure we're doing the "right thing". However, this makes the
compiled methods signficantly slower. In which case, there's almost no
point in avoiding method_missing at all. (See #8127 for a proposed
solution which takes this approach.)
This is an alternative approach which involves creating a subclass of
ActiveRecord::Relation for each AR class represented. So, with this
patch, Post.all.class != User.all.class. This means that the delegations
are compiled for and only apply to a single AR class. A compiled method
for Post.all will not be invoked from User.all.
This solves the above issues without incurring significant performance
penalties. It's designed to be relatively seamless, however the downside
is a bit of complexity and potentially confusion for a user who thinks
that Post.all and User.all should be instances of the same class.
Benchmark
---------
require 'active_record'
require 'benchmark/ips'
class Post < ActiveRecord::Base
establish_connection adapter: 'sqlite3', database: ':memory:'
connection.create_table :posts
def self.omg
:omg
end
end
relation = Post.all
Benchmark.ips do |r|
r.report('delegation') { relation.omg }
r.report('constructing') { Post.all }
end
Before
------
Calculating -------------------------------------
delegation 4392 i/100ms
constructing 4780 i/100ms
-------------------------------------------------
delegation 144235.9 (±27.7%) i/s - 663192 in 5.038075s
constructing 182015.5 (±21.2%) i/s - 850840 in 5.005364s
After
-----
Calculating -------------------------------------
delegation 6677 i/100ms
constructing 6260 i/100ms
-------------------------------------------------
delegation 166828.2 (±34.2%) i/s - 754501 in 5.001430s
constructing 116575.5 (±18.6%) i/s - 563400 in 5.036690s
Comments
--------
Bear in mind that the standard deviations in the above are huge, so we
can't compare the numbers too directly. However, we can conclude that
Relation construction has become a little slower (as we'd expect), but
not by a huge huge amount, and we can still construct a large number of
Relations quite quickly.
|
| | |
|
| |\
| |
| | |
AR::Relation#model would be a better API than AR::Relation#klass
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was requested by DHH to allow creating of one's own custom
association macros.
For example:
module Commentable
def has_many_comments(extra)
has_many :comments, -> { where(:foo).merge(extra) }
end
end
class Post < ActiveRecord::Base
extend Commentable
has_many_comments -> { where(:bar) }
end
|
| |/ |
|
| |
|
|
| |
Record.from("(#{sub_query.to_sql})") -> Record.from(sub_query)
Record.from("(#{sub_query.to_sql}) a") -> Record.from(sub_query, :a)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The main reason for this is that I want to separate the code that does
the mutating from the code that does the cloning.
|
| |
|
|
|
|
| |
See the CHANGELOG for details.
Fixes #950.
|
| | |
|
