Namespaced models in Rails: What's the state of the union?

Question

Hi all,

Since the beginning, Rails has had issues with namespaced models. As time went on, pretty much everybody gave up on using it. Myself included.

With Rails 2.3 out, I'd like an update on the situation. Specifics questions I have in mind are:

• first off, is it good to go?
• table naming, what rule to follow?
• associations, how to declare them with the least verbosity? how to name foreign key columns?
• auto-requiring, does it work if you put the model files in a subdir matching the namespace? or, how to name and where to place the files?
• generation, does the model generator handles namespaces successfully and correctly?
• generation, how about the scaffold generator, which includes controllers?
• any incompatibilities/quirkinesses one should be aware of?

Answer 1

We recently had a big debate about this inside our company. I think at the end of the day, we figured that if you can't namespace tables inside a database, it makes no sense to namespace the models. We settled on prefixing our models (User, UserAddress, UserEmailAddresses) and putting them into the users directory, then using:

config.load_paths << "#{RAILS_ROOT}/app/models/users"

to load the models. To control the verbosity in our models, we do this frequently:

has_many :addresses, :class_name => "UserAddress"

When generating, we create it as if there was no namespace (script/generate model UserAddress) then manually copy it to the user directory.

Shrug. I guess in the end all this really gives you is a cleaner directory structure, which is actually more trouble for a VIM user like me, but nice for TextMaters.

Answer 2

I would still stay away from it. Anything gained (which I'm not sure what that would honestly be) would definitely be lost when you consider the hassle and loss of brevity and clarity in your code.

My latest app has 87 resources, and includes administrative features all over the place. I see no need for namespacing, IMHO.

Answer 3

The best writeup I've seen on the issue is from Strictly Untyped. To my knowledge 2.3 hasn't resolved any issues, which means they're still unreliable.

Answer 4

Here's a real-world problem where namespacing makes some sense. Perhaps. Imagine that you have an application. Different clients want different extensions. The main system works for everyone, so you want to enhance in client-specific ways. So namespace "Client1::Extended_application" and "Client2::Enhanced_differently". The core models and main tables are the same, but the two different clients get their specific tables, and a role based authentication service can check to see whether the entire namespace is accessible or denied...

While that's do-able by creating longer file names with client-prefixes, it doesn't look as nice as the file system layout of namespaces, and namespaces allow easier identification and isolation of client-specific changes.