Re: [SUMMARY] Rails Core Weekly ( May 7-16)

Jamis Buck
Thu, 18 May 2006 13:22:44 -0000

Great summary, Rodney. Thanks!

- Jamis

On May 18, 2006, at 1:12 AM, Rodney Ramdas wrote:

> Dear List,
>
> I''ve written up summaries of the list for my own personal benefit.
I''d
> be happy to post them to the list if it''s useful. Here''s
one for last
> week or so. Suggestions, feedback are welcome.
>
>
> Rails Core Weekly 2 May 7 - May 16
>
> [ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/
> 001434.html ]
>
> Let''s kick of with Manfred Stienstra. He  submitted a very welcome
> addition to the Inflections documentation. Read all about pluralize,
> singularize, camelize, dasherize, demodulize, tableize (yuk) and
> constantize to name a few.
>
> [ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/
> 001436.html ]
>
> Meanwhile Francois Beausoleil has been busy as well. He wants to
> resort to voyeurism
> and needs to be able to add his observers to the environment.rb. But
> alas, plugins are not available during initialization phase. What to
> do ?
>
> Michael Koziarski (Koz) knows and recommends using
>
> config.after_initialize { }
>
> [ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/
> 001437.html ]
>
> Jeff Hall is experiencing short bursts of migraine brought on by
> erratic behaviour in ActiveRecord::Base#define_read_method(symbol,
> attr_name, column)
>
> Jeff explains his current medical condition in plain terms:
>
> "[..] define_read_method(symbol, attr_name, column) generates reader
> code for an attribute after Rails realizes there should be a reader
> method for it, correct? But the generated reader method body does not
> call read_attribute… instead it accesses the attribute directly and
> performs a type cast (if necessary).
> "
>
> A long, but interesting discussion follows. Turns out this
> implementation was chosen for performance reasons. Jeremy Kemper
> states that:
>
> "Inline type casting tailored to each attribute''s column type
is
> faster than does-it-all read_attribute."
>
> The original creator of this implementation, Stefan Kaes, steps
> forward when the discussion moves along uncharted territory. Stefan
> motivates his choice and rather excellently so, if you ask my opinion
> (but you didn''t so disregard that). He states 3 reasons for using
the
> inline method: avoiding method_missing and the analysis of the method
> name inside method_missing and finally avoiding taking in to account
> case sensitivity on string columns.
>
> [ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/
> 001448.html ]
>
> Stefan advises Jeff to monkey patch define_read_method if he wants his
> preferred behavior. That''s how he does it ( and now that secret is
> out).
>
> The week is still young when Michael Schoen''s DBA decides to do
the
> nasty on his Oracle database.
>
> [ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/
> 001452.html ]
>
> Consequently a test fails. Later Michael catches Jeremy in the act
> when Jeremy checks in patch ( Well intended: it closes an issue with
> PostgreSQL: "migrations support :limit with :integer columns by
> mapping limit < 4 to smallint, > 4 to bigint, and anything else to
> integer" to quote him. It also triggers Michael to write a patch to
> fix Oracle''s handling of sql_type. Jeremy is hoping for some
> specialized :limit handling for Oracle as well.
>
> [ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/
> 001470.html ]
>
> The Core''s patches are picking on poor Oracle databases though.
Some
> time later you see, Marcel Molina Jr. makes Oracle cry out loud when
> he checks in a patch that will take make sure MySQL boolean colum
> defaults are preserved in migrations.Sweet.
>
> Next the rising star of Joss Susser ( whom I''ve been known to call
> John) is rising some more. He ''s trying to put together a list of
> keywords used in tickets in Trac. Turns out there is no real list,
> just some conventions like using ''fd'' and
''risky''. Your eager Rails
> Core Weekly researchrodents are carefully monitoring this thread.
>
> On Monday Mongrel 0.3.13 is unleashed on to the Core by Zed Shaw. But
> he didn''t mean too.
>
> [ http://wrath.rubyonrails.org/pipermail/rails-core/2006-May/
> 001467.html ]
>
> What if you could do:
>
> @student.find_matches(:on => [ :last_name, :city ])
>
> Wouldn''t that make life so much fresher ? At least it smells good.
> That''s what Hampton must have been thinking when he feels the
water
> with this ''filtering'' feature. Kevin Clark and Tom Ward
like it and
> want to play. The discussion  is not over yet. Hopefully more next
> week.
>
> And that concludes this week''s Rail Core Weekly. Tune in next week
!
>
> ps If you find anything wrong with this report let me know.
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core