kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity
rails--rails/activerecord/test/cases/relation_test.rb

316 lines
10 KiB
Ruby
Raw Normal View History

please use ruby -I lib:test path/to/test.rb, or export RUBY_OPT
2011-06-06 14:17:44 -04:00
require "cases/helper"
adding more tests surrounding where_values_hash
2010-11-30 17:47:55 -05:00
require 'models/post'
require 'models/comment'
While merging relations preserve context for joins 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.
2013-04-10 08:34:47 -04:00
require 'models/author'
require 'models/rating'
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
module ActiveRecord
class RelationTest < ActiveRecord::TestCase
While merging relations preserve context for joins 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.
2013-04-10 08:34:47 -04:00
fixtures :posts, :comments, :authors
adding more tests surrounding where_values_hash
2010-11-30 17:47:55 -05:00
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
class FakeKlass < Struct.new(:table_name, :name)
testing Relation#table_name
2010-11-30 17:29:35 -05:00
end
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
def test_construction
include bind values from the default scope
2013-05-17 17:59:48 -04:00
relation = Relation.new FakeKlass, :b
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
assert_equal FakeKlass, relation.klass
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
assert_equal :b, relation.table
assert !relation.loaded, 'relation is not loaded'
end
AR::Relation#model would be a better API than AR::Relation#klass
2012-06-03 01:20:49 -04:00
def test_responds_to_model_and_returns_klass
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
assert_equal FakeKlass, relation.model
AR::Relation#model would be a better API than AR::Relation#klass
2012-06-03 01:20:49 -04:00
end
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
def test_initialize_single_values
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
Allow Relation#merge to take a hash
2012-04-13 07:10:51 -04:00
(Relation::SINGLE_VALUE_METHODS - [:create_with]).each do |method|
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
assert_nil relation.send("#{method}_value"), method.to_s
end
Allow Relation#merge to take a hash
2012-04-13 07:10:51 -04:00
assert_equal({}, relation.create_with_value)
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
end
def test_multi_value_initialize
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
Relation::MULTI_VALUE_METHODS.each do |method|
assert_equal [], relation.send("#{method}_values"), method.to_s
end
end
def test_extensions
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
assert_equal [], relation.extensions
end
testing Relation#table_name
2010-11-30 17:29:35 -05:00
adding more tests surrounding where_values_hash
2010-11-30 17:47:55 -05:00
def test_empty_where_values_hash
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
testing Relation#table_name
2010-11-30 17:29:35 -05:00
assert_equal({}, relation.where_values_hash)
use a hash to store relation values
2012-04-13 10:59:47 -04:00
relation.where! :hello
testing Relation#table_name
2010-11-30 17:29:35 -05:00
assert_equal({}, relation.where_values_hash)
end
adding more tests surrounding where_values_hash
2010-11-30 17:47:55 -05:00
def test_has_values
relation = Relation.new Post, Post.arel_table
use a hash to store relation values
2012-04-13 10:59:47 -04:00
relation.where! relation.table[:id].eq(10)
adding more tests surrounding where_values_hash
2010-11-30 17:47:55 -05:00
assert_equal({:id => 10}, relation.where_values_hash)
end
def test_values_wrong_table
relation = Relation.new Post, Post.arel_table
use a hash to store relation values
2012-04-13 10:59:47 -04:00
relation.where! Comment.arel_table[:id].eq(10)
adding more tests surrounding where_values_hash
2010-11-30 17:47:55 -05:00
assert_equal({}, relation.where_values_hash)
end
testing combined nodes are not traversed
2010-11-30 17:56:32 -05:00
def test_tree_is_not_traversed
relation = Relation.new Post, Post.arel_table
left = relation.table[:id].eq(10)
right = relation.table[:id].eq(10)
combine = left.and right
use a hash to store relation values
2012-04-13 10:59:47 -04:00
relation.where! combine
testing combined nodes are not traversed
2010-11-30 17:56:32 -05:00
assert_equal({}, relation.where_values_hash)
end
testing Relation#table_name
2010-11-30 17:29:35 -05:00
def test_table_name_delegates_to_klass
adding more tests surrounding where_values_hash
2010-11-30 17:47:55 -05:00
relation = Relation.new FakeKlass.new('foo'), :b
testing Relation#table_name
2010-11-30 17:29:35 -05:00
assert_equal 'foo', relation.table_name
end
def test_scope_for_create
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
testing Relation#table_name
2010-11-30 17:29:35 -05:00
assert_equal({}, relation.scope_for_create)
end
surrounding scope_for_create behavior
2010-11-30 18:44:30 -05:00
def test_create_with_value
relation = Relation.new Post, Post.arel_table
hash = { :hello => 'world' }
relation.create_with_value = hash
assert_equal hash, relation.scope_for_create
end
def test_create_with_value_with_wheres
relation = Relation.new Post, Post.arel_table
use a hash to store relation values
2012-04-13 10:59:47 -04:00
relation.where! relation.table[:id].eq(10)
surrounding scope_for_create behavior
2010-11-30 18:44:30 -05:00
relation.create_with_value = {:hello => 'world'}
assert_equal({:hello => 'world', :id => 10}, relation.scope_for_create)
end
making sure scope_for_create value is cached
2010-11-30 18:45:32 -05:00
# FIXME: is this really wanted or expected behavior?
def test_scope_for_create_is_cached
relation = Relation.new Post, Post.arel_table
assert_equal({}, relation.scope_for_create)
use a hash to store relation values
2012-04-13 10:59:47 -04:00
relation.where! relation.table[:id].eq(10)
making sure scope_for_create value is cached
2010-11-30 18:45:32 -05:00
assert_equal({}, relation.scope_for_create)
relation.create_with_value = {:hello => 'world'}
assert_equal({}, relation.scope_for_create)
end
isolating eager_loading? method
2010-11-30 19:10:49 -05:00
def test_empty_eager_loading?
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
isolating eager_loading? method
2010-11-30 19:10:49 -05:00
assert !relation.eager_loading?
end
def test_eager_load_values
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
use a hash to store relation values
2012-04-13 10:59:47 -04:00
relation.eager_load! :b
isolating eager_loading? method
2010-11-30 19:10:49 -05:00
assert relation.eager_loading?
end
Add ActiveRecord::Relation#references (#950)
2012-01-13 18:56:07 -05:00
def test_references_values
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
Add ActiveRecord::Relation#references (#950)
2012-01-13 18:56:07 -05:00
assert_equal [], relation.references_values
relation = relation.references(:foo).references(:omg, :lol)
store references as a string
2012-01-14 16:14:21 -05:00
assert_equal ['foo', 'omg', 'lol'], relation.references_values
Add ActiveRecord::Relation#references (#950)
2012-01-13 18:56:07 -05:00
end
def test_references_values_dont_duplicate
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
Add ActiveRecord::Relation#references (#950)
2012-01-13 18:56:07 -05:00
relation = relation.references(:foo).references(:foo)
store references as a string
2012-01-14 16:14:21 -05:00
assert_equal ['foo'], relation.references_values
Add ActiveRecord::Relation#references (#950)
2012-01-13 18:56:07 -05:00
end
Deprecate inferred JOINs with includes + SQL snippets. See the CHANGELOG for details. Fixes #950.
2012-01-16 16:14:34 -05:00
Allow Relation#merge to take a hash
2012-04-13 07:10:51 -04:00
test 'merging a hash into a relation' do
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new FakeKlass, :b
fix interpolation for hash merging
2012-04-22 05:34:55 -04:00
relation = relation.merge where: :lol, readonly: true
Allow Relation#merge to take a hash
2012-04-13 07:10:51 -04:00
fix interpolation for hash merging
2012-04-22 05:34:55 -04:00
assert_equal [:lol], relation.where_values
Allow Relation#merge to take a hash
2012-04-13 07:10:51 -04:00
assert_equal true, relation.readonly_value
end
test 'merging an empty hash into a relation' do
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
assert_equal [], Relation.new(FakeKlass, :b).merge({}).where_values
Allow Relation#merge to take a hash
2012-04-13 07:10:51 -04:00
end
assert valid keys
2012-04-13 07:15:43 -04:00
test 'merging a hash with unknown keys raises' do
assert_raises(ArgumentError) { Relation::HashMerger.new(nil, omg: 'lol') }
end
now we can just manipulate the values hash in #only and #except
2012-04-13 11:17:28 -04:00
test '#values returns a dup of the values' do
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new(FakeKlass, :b).where! :foo
now we can just manipulate the values hash in #only and #except
2012-04-13 11:17:28 -04:00
values = relation.values
values[:where] = nil
assert_not_nil relation.where_values
end
test 'relations can be created with a values hash' do
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new(FakeKlass, :b, where: [:foo])
now we can just manipulate the values hash in #only and #except
2012-04-13 11:17:28 -04:00
assert_equal [:foo], relation.where_values
allow merging a single where value
2012-04-22 03:49:56 -04:00
end
test 'merging a single where value' do
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
relation = Relation.new(FakeKlass, :b)
allow merging a single where value
2012-04-22 03:49:56 -04:00
relation.merge!(where: :foo)
assert_equal [:foo], relation.where_values
now we can just manipulate the values hash in #only and #except
2012-04-13 11:17:28 -04:00
end
fix interpolation for hash merging
2012-04-22 05:34:55 -04:00
test 'merging a hash interpolates conditions' do
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
klass = stub_everything
fix interpolation for hash merging
2012-04-22 05:34:55 -04:00
klass.stubs(:sanitize_sql).with(['foo = ?', 'bar']).returns('foo = bar')
relation = Relation.new(klass, :b)
relation.merge!(where: ['foo = ?', 'bar'])
assert_equal ['foo = bar'], relation.where_values
end
While merging relations preserve context for joins 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.
2013-04-10 08:34:47 -04:00
flatten merged join_values before building the joins 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.
2013-05-29 23:36:19 -04:00
def test_relation_merging_with_merged_joins_as_symbols
While merging relations preserve context for joins 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.
2013-04-10 08:34:47 -04:00
special_comments_with_ratings = SpecialComment.joins(:ratings)
posts_with_special_comments_with_ratings = Post.group("posts.id").joins(:special_comments).merge(special_comments_with_ratings)
Address ORA-00979: not a GROUP BY expression error
2013-04-11 09:27:07 -04:00
assert_equal 3, authors(:david).posts.merge(posts_with_special_comments_with_ratings).count.length
While merging relations preserve context for joins 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.
2013-04-10 08:34:47 -04:00
end
fix respond_to? for non selected column 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.
2013-04-13 21:19:17 -04:00
def test_respond_to_for_non_selected_element
if singletons belong to the contract, test them 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.
2013-04-20 03:26:07 -04:00
post = Post.select(:title).first
assert_equal false, post.respond_to?(:body), "post should not respond_to?(:body) since invoking it raises exception"
cleanup, assert on warning from postgres adapter
2013-05-07 05:36:14 -04:00
silence_warnings { post = Post.select("'title' as post_title").first }
if singletons belong to the contract, test them 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.
2013-04-20 03:26:07 -04:00
assert_equal false, post.respond_to?(:title), "post should not respond_to?(:body) since invoking it raises exception"
fix respond_to? for non selected column 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.
2013-04-13 21:19:17 -04:00
end
flatten merged join_values before building the joins 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.
2013-05-29 23:36:19 -04:00
def test_relation_merging_with_merged_joins_as_strings
join_string = "LEFT OUTER JOIN #{Rating.quoted_table_name} ON #{SpecialComment.quoted_table_name}.id = #{Rating.quoted_table_name}.comment_id"
special_comments_with_ratings = SpecialComment.joins join_string
posts_with_special_comments_with_ratings = Post.group("posts.id").joins(:special_comments).merge(special_comments_with_ratings)
assert_equal 3, authors(:david).posts.merge(posts_with_special_comments_with_ratings).count.length
end
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
end
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
class RelationMutationTest < ActiveSupport::TestCase
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
class FakeKlass < Struct.new(:table_name, :name)
Expand order(:symbol) to "table".symbol to prevent broken queries on PG. 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.
2013-02-25 05:40:30 -05:00
def quoted_table_name
%{"#{table_name}"}
end
Use separate Relation subclasses for each AR class 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.
2012-11-23 07:36:22 -05:00
end
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
def relation
Expand order(:symbol) to "table".symbol to prevent broken queries on PG. 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.
2013-02-25 05:40:30 -05:00
@relation ||= Relation.new FakeKlass.new('posts'), :b
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
end
Expand order(:symbol) to "table".symbol to prevent broken queries on PG. 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.
2013-02-25 05:40:30 -05:00
(Relation::MULTI_VALUE_METHODS - [:references, :extending, :order]).each do |method|
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
test "##{method}!" do
assert relation.public_send("#{method}!", :foo).equal?(relation)
assert_equal [:foo], relation.public_send("#{method}_values")
end
end
Expand order(:symbol) to "table".symbol to prevent broken queries on PG. 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.
2013-02-25 05:40:30 -05:00
test "#order!" do
assert relation.order!('name ASC').equal?(relation)
assert_equal ['name ASC'], relation.order_values
end
test "#order! with symbol prepends the table name" do
assert relation.order!(:name).equal?(relation)
assert_equal ['"posts".name ASC'], relation.order_values
end
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
test '#references!' do
assert relation.references!(:foo).equal?(relation)
assert relation.references_values.include?('foo')
end
Make Relation#extending work like other value methods
2012-04-13 07:58:13 -04:00
test 'extending!' do
fix association :extend option
2012-07-13 16:20:12 -04:00
mod, mod2 = Module.new, Module.new
Make Relation#extending work like other value methods
2012-04-13 07:58:13 -04:00
assert relation.extending!(mod).equal?(relation)
fix association :extend option
2012-07-13 16:20:12 -04:00
assert_equal [mod], relation.extending_values
Make Relation#extending work like other value methods
2012-04-13 07:58:13 -04:00
assert relation.is_a?(mod)
fix association :extend option
2012-07-13 16:20:12 -04:00
relation.extending!(mod2)
assert_equal [mod, mod2], relation.extending_values
Make Relation#extending work like other value methods
2012-04-13 07:58:13 -04:00
end
remove apply_finder_options call from AssociationScope
2012-04-13 08:12:28 -04:00
test 'extending! with empty args' do
relation.extending!
assert_equal [], relation.extending_values
end
Relation#from to accept other Relation objects Record.from("(#{sub_query.to_sql})") -> Record.from(sub_query) Record.from("(#{sub_query.to_sql}) a") -> Record.from(sub_query, :a)
2012-04-29 14:17:57 -04:00
(Relation::SINGLE_VALUE_METHODS - [:from, :lock, :reordering, :reverse_order, :create_with]).each do |method|
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
test "##{method}!" do
assert relation.public_send("#{method}!", :foo).equal?(relation)
assert_equal :foo, relation.public_send("#{method}_value")
end
end
Relation#from to accept other Relation objects Record.from("(#{sub_query.to_sql})") -> Record.from(sub_query) Record.from("(#{sub_query.to_sql}) a") -> Record.from(sub_query, :a)
2012-04-29 14:17:57 -04:00
test '#from!' do
assert relation.from!('foo').equal?(relation)
assert_equal ['foo', nil], relation.from_value
end
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
test '#lock!' do
assert relation.lock!('foo').equal?(relation)
assert_equal 'foo', relation.lock_value
end
test '#reorder!' do
relation = self.relation.order('foo')
assert relation.reorder!('bar').equal?(relation)
assert_equal ['bar'], relation.order_values
assert relation.reordering_value
end
test 'reverse_order!' do
assert relation.reverse_order!.equal?(relation)
assert relation.reverse_order_value
relation.reverse_order!
assert !relation.reverse_order_value
end
Allow Relation#merge to take a hash
2012-04-13 07:10:51 -04:00
test 'create_with!' do
assert relation.create_with!(foo: 'bar').equal?(relation)
assert_equal({foo: 'bar'}, relation.create_with_value)
end
Add Relation#merge!
2012-04-13 07:22:19 -04:00
test 'merge!' do
fix interpolation for hash merging
2012-04-22 05:34:55 -04:00
assert relation.merge!(where: :foo).equal?(relation)
assert_equal [:foo], relation.where_values
Add Relation#merge!
2012-04-13 07:22:19 -04:00
end
Allow Relation#merge to take a proc. 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
2012-08-03 05:50:49 -04:00
test 'merge with a proc' do
assert_equal [:foo], relation.merge(-> { where(:foo) }).where_values
end
ActiveRecord::Relation#none! method.
2012-09-24 18:59:07 -04:00
test 'none!' do
assert relation.none!.equal?(relation)
assert_equal [NullRelation], relation.extending_values
assert relation.is_a?(NullRelation)
end
rename `Relation#uniq` to `Relation#distinct`. `#uniq` still works. 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`.
2013-03-12 05:23:08 -04:00
test "distinct!" do
relation.distinct! :foo
assert_equal :foo, relation.distinct_value
assert_equal :foo, relation.uniq_value # deprecated access
end
test "uniq! was replaced by distinct!" do
relation.uniq! :foo
assert_equal :foo, relation.distinct_value
assert_equal :foo, relation.uniq_value # deprecated access
end
Add bang versions of relation query methods. The main reason for this is that I want to separate the code that does the mutating from the code that does the cloning.
2012-04-12 12:55:39 -04:00
end
adding a test for ActiveRecord::Relation
2010-11-30 17:10:55 -05:00
end
Copy permalink