Hi --
Emil Kampp wrote:
I have solved the problem.
It seems, that the table cannot be module, since this is a magic word.
I (like many others) have been caught in this trap (mine was a table called "transactions").
It would be nice if Rails did not have any reserved words at all, but I expect this is an artifact of the Ruby language itself. As Rails extends the classes and models of Ruby to perform its magic (for example has_many :things extends the current model by added methods for the :thing class) it can stomp on built in methods (such as method and transaction). This upsets Ruby and therefore Rails.
I have often thought patching Rails to remove all reserved words might be a useful exercise, but I have not come up with a way to make it work conceptually. I suspect the answer may be in overriding the built in Ruby methods to check for Rails specific ones, then passing control back to the built-ins if no methods exist (super?). While I *might* understand the concepts, this is way beyond my coding skills for now.
You're touching on several different, though in some ways similar, things here.
Ruby's reserved words -- if, def, and, class, and so forth -- are probably best not used as table or column names. They're not method names (though one of them, class, is also the name of a built-in method; its dual nature causes minor problems in Ruby already). But you'll still probably have cause to regret naming a column "not" or "then" or "true"....
You can see a complete list of Ruby keywords in the file keywords in the top level of the Ruby source tree.
So that's reserved words. To be avoided, but no big loss as they're weird names for tables anyway. Then there are methods.
Methods names that cause these blow-ups in Rails are either:
1. built-in Ruby methods, or 2. Rails methods
An example of the former is "display". If you name a controller action "display", you'll get a rather cryptic error to the effect that there's no such action. That's because (as I understand action_controller/base.rb) "display" is a built-in Ruby method and it gets masked out, along with the controller object's other existing methods, as a candidate action name. If you were allowed to name an action display (or inspect, or method, etc.), then the original method would be hidden from the object. You could detect that there was an override and try to circumvent it -- but, aside from being very slow, that would still leave the question of how you'd know which method was wanted. Presumably sometimes you'd want the new one, and sometimes the old one.
An example of blow-up method type #2 is "transaction", the one you mentioned. Ruby isn't involved here; that's purely a matter of Rails defining a method and then a user-defined method overriding it. I don't think there's much to do about this case either. If you name a column "attribute" or "reload" or "save", you're changing what the message means to the object and making it, I think, literally impossible to know unambiguously what obj.reload (or whatever) is supposed to mean.
It's all a bit of an obstacle course, but in the long run the number of options that get ruled out is fairly small.
David