views:

795

answers:

3

I have a standard many-to-many relationship between users and roles in my Rails app:

class User < ActiveRecord::Base
  has_many :user_roles
  has_many :roles, :through => :user_roles
end

I want to make sure that a user can only be assigned any role once. Any attempt to insert a duplicate should ignore the request, not throw an error or cause validation failure. What I really want to represent is a "set", where inserting an element that already exists in the set has no effect. {1,2,3} U {1} = {1,2,3}, not {1,1,2,3}.

I realize that I can do it like this:

user.roles << role unless user.roles.include?(role)

or by creating a wrapper method (e.g. add_to_roles(role)), but I was hoping for some idiomatic way to make it automatic via the association, so that I can write:

user.roles << role  # automatically checks roles.include?

and it just does the work for me. This way, I don't have to remember to check for dups or to use the custom method. Is there something in the framework I'm missing? I first thought the :uniq option to has_many would do it, but it's basically just "select distinct."

Is there a way to do this declaratively? If not, maybe by using an association extension?

Here's an example of how the default behavior fails:

    >> u = User.create
      User Create (0.6ms)   INSERT INTO "users" ("name") VALUES(NULL)
    => #<User id: 3, name: nil>
    >> u.roles << Role.first
      Role Load (0.5ms)   SELECT * FROM "roles" LIMIT 1
      UserRole Create (0.5ms)   INSERT INTO "user_roles" ("role_id", "user_id") VALUES(1, 3)
      Role Load (0.4ms)   SELECT "roles".* FROM "roles" INNER JOIN "user_roles" ON "roles".id = "user_roles".role_id WHERE (("user_roles".user_id = 3)) 
    => [#<Role id: 1, name: "1">]
    >> u.roles << Role.first
      Role Load (0.4ms)   SELECT * FROM "roles" LIMIT 1
      UserRole Create (0.5ms)   INSERT INTO "user_roles" ("role_id", "user_id") VALUES(1, 3)
    => [#<Role id: 1, name: "1">, #<Role id: 1, name: "1">]
A: 

Perhaps it is possible to create the validation rule

validates_uniqueness_of :user_roles

then catch the validation exception and carry on gracefully. However, this feels really hacky and is very inelegant, if even possible.

Schrockwell
+3  A: 

As long as the appended role is an ActiveRecord object, what you are doing:

user.roles << role

Should de-duplicate automatically for :has_many associations.

For has_many :through, try:

class User
  has_many :roles, :through => :user_roles do
    def <<(*items)
      super( items - proxy_owner.roles )
    end
  end
end

if super doesn't work, you may need to set up an alias_method_chain.

austinfromboston
It doesn't work like that. I'll update the post to include the test.
KingPong
Thanks, I'll try the association extension.
KingPong
That worked perfectly. Thanks! The part I was missing when I tried something like this myself was the proxy_owner bit.
KingPong
For posterity, the above method can be shortened and genericized to: def <<(*items) super(items - proxy_target) end
KingPong
That was my first version :). I didn't have actual models set up and was concerned that super(nil) might cause errors. updating the answer with your version and leaving the sub-par code here ( for posterity ): def <<(*items); new_items = items - proxy_owner.roles; super( new_items ) unless new_items.empty?; end
austinfromboston
+1  A: 

i think the proper validation rule is in your users_roles join model:

validates_uniqueness_of :user_id, :scope => [:role_id]
bdon
Thanks. That doesn't actually do what I want though (which is a set-like behavior), and I've clarified what that is in the original post. Sorry 'bout that.
KingPong
I think this is the best answer for your problem. If you are careful in creating your interface, a user would have to hack it to add the wrong role anyway, in which case a validation exception is a totally suitable response.
austinfromboston
Heh, are you crazy? Users don't add their own roles :-)The typical use case is that a user becomes a member of a role as a side effect of something else. For example, buying a particular product. Other products may also provide the same role, so there is a chance for duplication there. I'd rather do the duplication checking in one place than in whatever random places need to ensure a user has a role. In this sense, giving a user a role he already has is NOT an error condition.
KingPong