2011-06-06 14:17:44 -04:00
|
|
|
require "cases/helper"
|
2010-11-30 17:47:55 -05:00
|
|
|
require 'models/post'
|
|
|
|
|
require 'models/comment'
|
2010-11-30 17:10:55 -05:00
|
|
|
|
|
|
|
|
module ActiveRecord
|
|
|
|
|
class RelationTest < ActiveRecord::TestCase
|
2010-11-30 17:47:55 -05:00
|
|
|
fixtures :posts, :comments
|
|
|
|
|
|
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)
|
2010-11-30 17:29:35 -05:00
|
|
|
end
|
|
|
|
|
|
2010-11-30 17:10:55 -05:00
|
|
|
def test_construction
|
|
|
|
|
relation = nil
|
|
|
|
|
assert_nothing_raised 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
|
2010-11-30 17:10:55 -05:00
|
|
|
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
|
|
|
assert_equal FakeKlass, relation.klass
|
2010-11-30 17:10:55 -05:00
|
|
|
assert_equal :b, relation.table
|
|
|
|
|
assert !relation.loaded, 'relation is not loaded'
|
|
|
|
|
end
|
|
|
|
|
|
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
|
2012-06-03 01:20:49 -04:00
|
|
|
end
|
|
|
|
|
|
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
|
2012-04-13 07:10:51 -04:00
|
|
|
(Relation::SINGLE_VALUE_METHODS - [:create_with]).each do |method|
|
2010-11-30 17:10:55 -05:00
|
|
|
assert_nil relation.send("#{method}_value"), method.to_s
|
|
|
|
|
end
|
2012-04-13 07:10:51 -04:00
|
|
|
assert_equal({}, relation.create_with_value)
|
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
|
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
|
2010-11-30 17:10:55 -05:00
|
|
|
assert_equal [], relation.extensions
|
|
|
|
|
end
|
2010-11-30 17:29:35 -05:00
|
|
|
|
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
|
2010-11-30 17:29:35 -05:00
|
|
|
assert_equal({}, relation.where_values_hash)
|
|
|
|
|
|
2012-04-13 10:59:47 -04:00
|
|
|
relation.where! :hello
|
2010-11-30 17:29:35 -05:00
|
|
|
assert_equal({}, relation.where_values_hash)
|
|
|
|
|
end
|
|
|
|
|
|
2010-11-30 17:47:55 -05:00
|
|
|
def test_has_values
|
|
|
|
|
relation = Relation.new Post, Post.arel_table
|
2012-04-13 10:59:47 -04:00
|
|
|
relation.where! relation.table[:id].eq(10)
|
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
|
2012-04-13 10:59:47 -04:00
|
|
|
relation.where! Comment.arel_table[:id].eq(10)
|
2010-11-30 17:47:55 -05:00
|
|
|
assert_equal({}, relation.where_values_hash)
|
|
|
|
|
end
|
|
|
|
|
|
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
|
2012-04-13 10:59:47 -04:00
|
|
|
relation.where! combine
|
2010-11-30 17:56:32 -05:00
|
|
|
assert_equal({}, relation.where_values_hash)
|
|
|
|
|
end
|
|
|
|
|
|
2010-11-30 17:29:35 -05:00
|
|
|
def test_table_name_delegates_to_klass
|
2010-11-30 17:47:55 -05:00
|
|
|
relation = Relation.new FakeKlass.new('foo'), :b
|
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
|
2010-11-30 17:29:35 -05:00
|
|
|
assert_equal({}, relation.scope_for_create)
|
|
|
|
|
end
|
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
|
2012-04-13 10:59:47 -04:00
|
|
|
relation.where! relation.table[:id].eq(10)
|
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
|
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)
|
|
|
|
|
|
2012-04-13 10:59:47 -04:00
|
|
|
relation.where! relation.table[:id].eq(10)
|
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
|
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
|
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
|
2012-04-13 10:59:47 -04:00
|
|
|
relation.eager_load! :b
|
2010-11-30 19:10:49 -05:00
|
|
|
assert relation.eager_loading?
|
|
|
|
|
end
|
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
|
2012-01-13 18:56:07 -05:00
|
|
|
assert_equal [], relation.references_values
|
|
|
|
|
relation = relation.references(:foo).references(:omg, :lol)
|
2012-01-14 16:14:21 -05:00
|
|
|
assert_equal ['foo', 'omg', 'lol'], relation.references_values
|
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
|
2012-01-13 18:56:07 -05:00
|
|
|
relation = relation.references(:foo).references(:foo)
|
2012-01-14 16:14:21 -05:00
|
|
|
assert_equal ['foo'], relation.references_values
|
2012-01-13 18:56:07 -05:00
|
|
|
end
|
2012-01-16 16:14:34 -05:00
|
|
|
|
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
|
2012-04-22 05:34:55 -04:00
|
|
|
relation = relation.merge where: :lol, readonly: true
|
2012-04-13 07:10:51 -04:00
|
|
|
|
2012-04-22 05:34:55 -04:00
|
|
|
assert_equal [:lol], relation.where_values
|
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
|
2012-04-13 07:10:51 -04:00
|
|
|
end
|
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
|
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
|
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])
|
2012-04-13 11:17:28 -04:00
|
|
|
assert_equal [:foo], relation.where_values
|
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)
|
2012-04-22 03:49:56 -04:00
|
|
|
relation.merge!(where: :foo)
|
|
|
|
|
assert_equal [:foo], relation.where_values
|
2012-04-13 11:17:28 -04:00
|
|
|
end
|
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
|
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
|
2010-11-30 17:10:55 -05:00
|
|
|
end
|
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)
|
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
|
|
|
|
|
|
2012-04-12 12:55:39 -04:00
|
|
|
def relation
|
2013-02-25 05:40:30 -05:00
|
|
|
@relation ||= Relation.new FakeKlass.new('posts'), :b
|
2012-04-12 12:55:39 -04:00
|
|
|
end
|
|
|
|
|
|
2013-02-25 05:40:30 -05:00
|
|
|
(Relation::MULTI_VALUE_METHODS - [:references, :extending, :order]).each do |method|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
2012-04-12 12:55:39 -04:00
|
|
|
test '#references!' do
|
|
|
|
|
assert relation.references!(:foo).equal?(relation)
|
|
|
|
|
assert relation.references_values.include?('foo')
|
|
|
|
|
end
|
|
|
|
|
|
2012-04-13 07:58:13 -04:00
|
|
|
test 'extending!' do
|
2012-07-13 16:20:12 -04:00
|
|
|
mod, mod2 = Module.new, Module.new
|
2012-04-13 07:58:13 -04:00
|
|
|
|
|
|
|
|
assert relation.extending!(mod).equal?(relation)
|
2012-07-13 16:20:12 -04:00
|
|
|
assert_equal [mod], relation.extending_values
|
2012-04-13 07:58:13 -04:00
|
|
|
assert relation.is_a?(mod)
|
2012-07-13 16:20:12 -04:00
|
|
|
|
|
|
|
|
relation.extending!(mod2)
|
|
|
|
|
assert_equal [mod, mod2], relation.extending_values
|
2012-04-13 07:58:13 -04:00
|
|
|
end
|
|
|
|
|
|
2012-04-13 08:12:28 -04:00
|
|
|
test 'extending! with empty args' do
|
|
|
|
|
relation.extending!
|
|
|
|
|
assert_equal [], relation.extending_values
|
|
|
|
|
end
|
|
|
|
|
|
2012-04-29 14:17:57 -04:00
|
|
|
(Relation::SINGLE_VALUE_METHODS - [:from, :lock, :reordering, :reverse_order, :create_with]).each do |method|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
2012-04-13 07:22:19 -04:00
|
|
|
|
|
|
|
|
test 'merge!' do
|
2012-04-22 05:34:55 -04:00
|
|
|
assert relation.merge!(where: :foo).equal?(relation)
|
|
|
|
|
assert_equal [:foo], relation.where_values
|
2012-04-13 07:22:19 -04:00
|
|
|
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
|
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
|
2012-04-12 12:55:39 -04:00
|
|
|
end
|
2010-11-30 17:10:55 -05:00
|
|
|
end
|