Returning Block on Association Extension Causes Proxy Owner To Load Target
Reported by Ken Collins | August 13th, 2008 @ 06:30 PM | in 2.x
If this were a bug that could be fixed I'd take a stab at the tests, but I pretty much doubt that it is. So this ticket is more of a warning to others. I have found that using a returning block inside of an association extension causes the proxy owner to load the target. I came across this bug in 1.2.6 and see that the same results happen in 2.1. Here is some code that demonstrates the issue.
Because our production app uses a good deal of association extensions and there is a lot of data, this started to really affect performance. If any things this can be accounted for either in the implementation of returning and/or the association proxy classes, please let me know and I can take a stab at a test.
class User < ActiveRecord::Base
has_many :articles, :extend => FooBarReturning
end
module FooBarReturning
def foo
c = build
# DOES NOT CAUSE SELECT ALL AS NORMAL
end
def bar
returning c = build do
# SELECT * FROM "articles" WHERE ("columns".user_id = 1)
end
end
def returning
returning build do |c|
# SELECT * FROM "articles" WHERE ("columns".user_id = 1)
end
end
end
class User < ActiveRecord::Base
has_many :articles do
def foo_bar_returning
returning c = build do
# SELECT * FROM "articles" WHERE ("columns".user_id = 1)
end
end
end
end
Comments and changes to this ticket
-
Ken Collins August 13th, 2008 @ 06:35 PM
I forgot to mention that if you used the returning block inside of a controller (just anywhere outside of an association extension) that the SQL is just fine. The issue only seems to be when using the returning block in an association extensions.
ALSO, I have a type above... my example association method that shows that either use of returning should have been as follows.
module FooBarReturning def foo_bar_returning returning build do |c| # SELECT * FROM "articles" WHERE ("columns".user_id = 1) end end end -
Frederick Cheung August 13th, 2008 @ 09:09 PM
returning is a method activesupport adds to Object, so it's available everywhere. Except on an association proxy, because association proxies undef all their methods (so that they filter through to the target), including returning.
With returning you don't care who you call returning on though, so something like
Object.returning build do |c| ... endSeing as returning doesn't depending on who its called on (it's just injected everywhere for convenience), arguably you could just not undef it.
-
Ken Collins August 13th, 2008 @ 09:15 PM
Not sure what you are saying... returning works in the association extension but it just has ILL EFFECTS of loading the target. I am pretty sure Object.returning does the same.
-
Frederick Cheung August 13th, 2008 @ 09:18 PM
because returning is undeffed on the proxy, it has to load the array in order to call it. By calling it on Object you avoid that (the choice of Object is arbitrary). try it.
-
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
Creating or reviewing a patch
See the contributor guide.
Creating a feature request
Please don't. If you want a new feature in Rails, you'll have to pull up your sleeves and get busy yourself. Or convince someone else to do it. See the contributor guide on how to get going. But posting them here is just going to lead to ticket root.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
