Hi, so I’m new to rails development, and I’m following a book called
Practical Rails: Social Networking Sites. There’s a user role system
that the book develops, each user has a one or more roles and vice
versa. So I have the tables users, roles and roles_users (which
connects users to roles and vice versa).
In the Role model I have has_and_belongs_to_many :users and in the
User model I have has_and_belongs_to_many: roles.
To get the joint table I ran the command: script/generate migration
CreateRolesUsersJoin and in the 2010301_create_roles_users_join.rb
file I have the following:
so after that I run db:migrate and I expect that a new user called
Admin should be created int eh database and the roles_users database
should have one record in it connecting user Admin and role
Administrator… but my databases are empty.
Any suggestion? I’m using rails 2.3.5 and I think the book uses an
older version so I suspect something to do with a version difference,
but not sure.
Hi, ok so it’s fixed now and I have no idea how. I don’t know what the
console output was the first time I ran the db:migrate command. I tried
running it quite a few times after that and it wouldn’t output anything
new.
Anyway, I ran db:reset and everything work now.
Just to answer the other questions, yes the Administrator role was being
created properly and User validations were not failing. Something else
was
up I guess. Maybe join tables have to be created at the same time? I had
the
users table set up a while ago…
That would make more sense creating the Administrator at the time of the
users migration, but I’m following a book and the roles were created
later
so I suppose the author just figured he’d throw it in there or
something. I
do not have logic that prevents the admin from being deleted at this
point
either. Noted
Thanks.
Is it standard practice to have the classes (Role and User in this case)
defined inside the migration RolesUsersJoin, wouldn’t it be inconvenient
since I would have my Role and User model defined somewhere else anyway?
Or
are you saying I should not define a User and Role elsewhere but just
have
them inside the RolesUsersJoin class?
CreateRolesUsersJoin and in the 2010301_create_roles_users_join.rb
file I have the following:
class CreateRolesUsersJoin < ActiveRecord::Migration
class User < ActiveRecord::Base
has_and_belongs_to_many: roles
# include code as needed (like a before_save :encrypt_password)
end
class Role < ActiveRecord::Base
has_and_belongs_to_many :users
end
admin_role = Role.find_by_name(‘Administrator’)
admin_user.roles << admin_role
end
end
end
Thanks in advance.
Before you use a Model inside a migration, it’s a good idea to create
a special class for it inside the migration (which is why I added
the class around your code). These models should have just enough
content for the purpose of the migration. I’m not sure about the
HABTM relationships, but I threw .reset_column_information calls in
there for both models since the roles_users table is new and common to
both.
One question though, why didn’t you create the Admin user when the
User table was created? Do you have logic to keep the last user with
an ‘Administrator’ role from being deleted?
Is it standard practice to have the classes (Role and User in this
case) defined inside the migration RolesUsersJoin, wouldn’t it be
inconvenient since I would have my Role and User model defined
somewhere else anyway? Or are you saying I should not define a User
and Role elsewhere but just have them inside the RolesUsersJoin class?
Ali
You want the normal models defined in their own files as is the
convention. However, if you plan to manipulate the data through a
model during a migration, then having a “local” version of that model
defined as a nested class will shield you from problems later if the
normal model evolves to have columns not present at the time of the
migration that does the manipulation. (Adding a column to the table
and then including a validation in the model is one way to do it and
if you’re making small migrations, it’s not too hard to have a set of
migrations that are deployed to production at the same time that are
“incompatible” with each other.)
Some will claim that this is being paranoid, but I’ve helped at least
two other projects (not my own) when they encountered just such crises.
If you are only doing “migration” things (i.e., Data Definition
Language stuff in SQL-speak), then there’s no need for a nested class.
-Rob
has_and_belongs_to_many: roles
t.column :role_id, :integer, :null => false
:pwd => ‘admin’,
so after that I run db:migrate and I expect that a new user called
