Rails core - May 2009 - 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
================================================-- create_table(:user_tags)
   -> 0.0022s
==  CreateUserTags: migrated (0.0029s)
======================================% script/console
>> User::Tag
=> User::Tag(Table doesn''t exist)
>> User::Tag.table_name
=> "tags"

Should the model "undecorate" and "demodulize" the class
name while
figuring out the table name, as it does now? If so, the generated
model migration needs to be fixed so that it does the same.

Perhaps it makes more sense, though, for the model to stop
disregarding namespaces when detecting table names?

I''m happy to provide a patch, but wanted to clarify the desired
behavior, first.

Stephen

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


On May 18, 2009, at 7:57 PM, Stephen Celis wrote:
>
> 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
> ================================================> --
create_table(:user_tags)
>   -> 0.0022s
> ==  CreateUserTags: migrated (0.0029s)
> ======================================> % script/console
>>> User::Tag
> => User::Tag(Table doesn''t exist)
>>> User::Tag.table_name
> => "tags"
>
> Should the model "undecorate" and "demodulize" the
class name while
> figuring out the table name, as it does now? If so, the generated
> model migration needs to be fixed so that it does the same.
>
> Perhaps it makes more sense, though, for the model to stop
> disregarding namespaces when detecting table names?
>
> I''m happy to provide a patch, but wanted to clarify the desired
> behavior, first.
>
> Stephen
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google  
> Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

Hi,

On May 18, 9:05 pm, Ken Collins <k...@metaskills.net>
wrote:
> 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.
Extra work is fine, whether setting a prefix or explicitly declaring
the table name, but a namespaced model should still work out of the
box, right? Do you agree that, at the very least, the generated
migration should strip out the namespace?

Stephen

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

  - Ken

On May 18, 2009, at 11:27 PM, Stephen Celis wrote:
>
> Hi,
>
> On May 18, 9:05 pm, Ken Collins <k...@metaskills.net> wrote:
>> 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.
>
> Extra work is fine, whether setting a prefix or explicitly declaring
> the table name, but a namespaced model should still work out of the
> box, right? Do you agree that, at the very least, the generated
> migration should strip out the namespace?
>
> Stephen
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google  
> Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

On 19 May 2009, at 14:09, Ken Collins wrote:
> Agreed. And along the same lines, the fixture file should perhaps  
> just be named "users" too.

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