I wanted to gather some feedback from people about nested models and the assumptions that they make about the underlying database structure. As I see it, the primary function of nesting model classes inside of modules is to provide a namespacing mechanism. Given that a model class called Admin::Foo and User::Foo will both use the table name 'foos' by default this namespacing seems to be incomplete. You could always specify a different table name for each class but this is a pretty manual approach to namespacing. The only feasible solution I could come up with is to have a class named Admin::Foo assume a default table name of admin__foos. The double _ would prevent a collision with a class named AdminFoo and seems to me the most logical way to differentiate between the two. Just wanted to throw the topic out there, see what people thought, etc. I would definitely consider submitting a patch if it seems like there is some interest...
on 2007-03-31 06:00
on 2007-04-01 11:16
Has Rails even been designed with namespaces in mind? Is it possible to put models, controllers etc. in namespaces in a standard Rails way? Erik
on 2007-04-02 05:35
I'm not really sure what the design decisions behind being able to organize models and controllers into modules were but I can't imagine that namespacing was not among them. In answer to your question, yes, controllers and models can be namespaced by placing them in a module (so you can have a file called apps/controllers/admin/ login_controller.rb containing a class called Admin::LoginController and another file called apps/controllers/user/login_controller.rb containing a class called User::LoginController). You can effectively do the same thing with models classes. The problem I am pointing out is that even if you have models organized in this way there is no standard way to break up the backing database tables in such a way that collisions will not occur... ~Ross