Add blocks to AR create and update
Reported by Adam Meehan | April 22nd, 2008 @ 05:24 PM
This patch adds the block syntax to the ActiveRecord class methods create and update.
For example it allows this:
@person = Person.create(params[:person]) do |p|
p.has_rails_patch = false
p.set_status :uncool
end
@person = Person.update(params[:id], params[:person]) do |p|
p.has_rails_patch = true
p.set_status :cool
end
And for the array variants of these methods it will call the block for each record:
Person.create([{:name => 'Matz'}, {:name => 'David'}]) do |p|
p.set_status :cool
end
Both people will be set to cool status.
The create! is also patched.
Tests included.
Thanks,
Adam.
Comments and changes to this ticket
-
Adam Meehan April 23rd, 2008 @ 03:27 AM
Updated patch with conforming more to rails conventions with blocks.
-
-
-
-
matthuhiggins April 27th, 2008 @ 12:53 AM
Perhaps a tangent, but why not replace
object = new(attributes)
yield(object) if block_given?
object.save
object
with
returning new(attributes) do |object|
yield(object) if block_given?
object.save
end
-
Adam Meehan April 27th, 2008 @ 01:24 AM
Sure that would be nice. I was not sure how often 'returning' was being used in rails code. I thought of it more as for external use.
From greping the rails edge code I see there is some use of it. I am happy to change it to the returning convention if thats the way rails is going.
-
Adam Meehan April 27th, 2008 @ 01:36 AM
Added another patch which uses returning. I will let the core team decide what they prefer.
Thanks for the suggestion Matt.
-
matthuhiggins April 27th, 2008 @ 04:38 PM
Using returning reduces performance. Since create is a common operation, my suggestion might not be worth it.
-
Adam Meehan April 27th, 2008 @ 04:46 PM
I did wonder. I will let the core team decide based on what they know and would prefer. Both patches are there.
-
-
Repository April 30th, 2008 @ 11:14 PM
- → State changed from “new” to “resolved”
(from [dd120ede53eaf71dee76894998a81626b7a689fc]) Added block-setting of attributes for Base.create like Base.new already has (Adam Meehan) [#39 state:resolved]
-
david (at loudthinking) April 30th, 2008 @ 11:15 PM
- → State changed from “resolved” to “new”
The create block is good stuff, but I don't think the update one warrants enough use to be included. Base#update is kinda suspect as is.
-
david (at loudthinking) April 30th, 2008 @ 11:15 PM
- → State changed from “new” to “resolved”
-
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
The latest development for the 1.2.x and 2.0.x releases are on the 1-2-stable and 2-0-stable branches.
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".
