Rails Core Weekly May 23 - May 28
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001500.html ]
On may 23 I just missed an opportunity to report on a patch
(http://dev.rubyonrails.org/ticket/5167) politely submitted by
Francois Beausoleil that adds a generator for observers. Marcel
Molina Jr. hates repeating himself so a generator for observers is
most welcome. The patch is applied quickly. Thank your Francois !
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001506.html ]
Just one day later Laszlo Gyula displays his concern about
ActiveRecord#update_attributes which updates all the attributes from a
passed-in hash as it is used in scaffolding. The attributes are then
accessible to mere ordinary mortals and vulnerable to URL/form hackers
. So Laszlo devised a cunning plan to make this not so, anymore. The
plan results in:
update_attributes params[:shop], {:allow => [:header_color1,
:header_color:2]}
However Marcel whispers quietly beneath his beard that you can use
ActiveRecord#attr_protected (
http://api.rubyonrails.com/classes/ActiveRecord/Base.html#M000873) :
class Customer < ActiveRecord::Base
attr_protected :credit_rating
end
but alas this is not what Laszlo had in mind. Tim Lucas closes the
thread by providing a wonderful alternative:
%w(name email address).each { |f| @person[f] = params[:person][f] }
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001503.html ]
Remember how in last RCW we we''re perplexed by Hampton''s swift
implementation of
Person.find(:all,
:conditions => { :last_name => "Catlin", :status
=> 1 },
:limit => 2)
i.e passing a hash as :conditions to find() ?
Well, not everyone is convinced this is the right thing to do. Tom
Ward explains where the sweetspot is on Hampton''s patch (SQL is evil,
please do not write SQL) and DHH is sold on the idea that with
Hampton''s patch hashes are easily turned into ''AND''
clauses ( within
SQL statements). DHH also enquires what part of the plugin
architecture people would like to see refactored...
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001513.html ]
This is a busy day. Derrick Spell needs his email address changed in
the Openbase adapter and submits a tiny patch. Marcel makes it so even
though he is not bored at al. See, the little things do matter.
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001516.html ]
Now I''ve said before that when Josh Susser speaks you should pay
attention. That time has come again: Josh has questions after
thoroughly investigating #build and #create in the HABTM class.
#build is a method from HABTM while #create is inheretied form the
AssocationCollection. Turns out this is by design and not a remnant of
past endeavours. DHH takes Josh up on his offer to write some tests
for #create: "Please do make it work".
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001532.html ]
Dee Zsombor submits a patch ( http://dev.rubyonrails.org/ticket/5133 )
that adds the -a option to the spawner that''ll make applicable fcgi
listeners bind to 127.0.0.1 instead of 0.0.0.0 for security reasons.
Koz expresses his concern and asks if the default can remain 0.0.0.0
and that the user is to be alerted that it should be 127.0.0.1. Dee
agrees and fixes the patch.
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001522.html ]
Michael Schoen discusses adding bind variables to the Oracle adapter.
Using bind variables potentially speeds things up significantly at
least on the Oracle side of things. Among other things he would like
to know are whether other databases have a similar concept and if so
whether bind variable peeking should be implemented on a higher level
(i.e. in the abstract adapter). The consensus is that if a database
supports bind variables then yes, bind vars should be used (Blair
Zajac). Jeremy Kemper knows that Postgresql suports bind variables and
the native postgresql bindings actually uses them.
Blair let''s us know his DBA has enabled cursor sharing to alleviate
the performance issues which turns out is what Michael Schoen is doing
in his production environment as well but it has issues so that
solution is not ideal.
Anyway, some time later Michael submits the patch (
http://dev.rubyonrails.org/ticket/5199) but asks that the patch should
not be commited. His solution uses some regexp approach that does work
but is not an a solution he likes. So then this means we have lots of
work to do here. I''m sure we''ll here more about bind vars and
Rails in
the future.
[ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/001540.html ]
Then there is the issue of spam on the Rails wiki. Justin Forder
summarizes a typical wiki day. Please read the thread and you will
feel dirty afterwards. Action must be taken but how ? A discussion in
ongoing at this very moment.
This concludes this weeks RCW. More next week,
Rodney
http://www.pinupgeek.com (in case you like a RSS feed of the summaries)
