Namespaced model/migration table name inconsistency. Expected behavior?

Came across a model/migration table discrepancy. Here's an example:

% script/generate model user/tag
      create app/models/user
      create test/unit/user
      create test/fixtures/user
      create app/models/user/tag.rb
      create test/unit/user/tag_test.rb
      create test/fixtures/user_tags.yml
      exists db/migrate
      create db/migrate/20090518233442_create_user_tags.rb
% rake db:migrate
== CreateUserTags: migrating

In my opinion, namespaces should not automagically qualify a table name. It would seem to me that the if this were made true, then all sorts of external plugins would go crazy as their namespaced models would be using a new table name. Maybe it's just me, but I've always liked namespacing and thought the little bit of extra work outside generators was intentionally part of what needed to be done... i.e. not everything can be reflected.

  - Ken


Agreed. And along the same lines, the fixture file should perhaps just be named "users" too.

  - Ken

Unfortunately, it's not quite as simple as that. If the parent of the class is another AR model class then the table name will be prefixed with that model's table name so you wouldn't want to just strip it out. The question is do we want to start loading models in the generator to see if it's a AR class or a generic model or do we assume a module and then leave it to the developer to fix the migrations, etc.

Andrew White