Update 07/11/2008: A fix has been committed for the :named_scope_-column-collision issue.
Interesting Things
- In Rails 2.0.2, we have seen a strange behavior when you have a
belongs_toassociation declared on an ActiveRecord class, but the table does not have a foreign key for that relationship. Within a session, everything appears normal. The child object will still be saved, the parent object can even be reloaded. But by the next session, the child object is in the database, but cannot be retrieved. - When using
named_scope, adding a:joinsoption will "mix-in" all of the attributes from that join table into your retrieved object, potentially overwriting any colliding attributes (includingid... ouch!). There was consensus that this was a valuable feature, when used "properly". Adding:selectoption can avoid this, or use:include. - We ran into an issue when using the JS Routes plugin in combination with Rails' asset packaging. When asset packaging is invoked using
<%= javascript_include_tag 'named_routes', 'xxx', :cache => true %>thenamed_routes.jsfile usually has not been generated, and application crashes at startup. Solution: we created a rake task to generate thenamed_routes.jsfile and run that as part of our deploy process.
Ask for Help
"Why did my JS
respond_toblock suddenly start rendering the HTML template instead of the RJS template?"
Rails 2.0.2; controller, action, respond_to block all work as expected. Just wrong file gets rendered. They fixed the problem by adding an explicit call to render but this should not be necessary. Suggestion is to move from the template.rhtml naming scheme to template.mime-type.render-engine scheme and see if it is fixed.
Thanks for mentioning the named-scope / join issue... you might also consider aliasing the tables you join in, to avoid conflicts with other scopes you might merge in later ... see here.
On the belongs_to with no foreign key thing -- do you mean a foreign key not formally defined in the database, or you mean there isn't a column to actually join the two tables?
I guess in the latter case, the behaviour doesn't really surprise me that much; it sounds like the sort of way ActiveRecord would behave (with bugs hard to track down). I imagine belongs_to doesn't check to see if that column is actually there before adding the getter/setter methods.
Yeah the column was missing from the database. Some people mentioned that this used to be a problem with all the associations, but they've put some checking into some now (but apparently not belongs_to)
A fix has been committed for the
:named_scope_-column-collision issue