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
