Can someone have a role that is not attached to an agenda? If so I think I would prefer setting it up so Agendas have many Roles.
class User < ActiveRecord::Base has_many :agendas has_many :roles, through: agendas end class Agenda < ActiveRecord::Base belongs_to :user has_many :roles end class Role < ActiveRecord::Base belongs_to :agenda end If a role is more general, I'd take a look at how people do authorization. At Q-Centrix we have a user table, a roles table, and a join-table of the two. We then use the user_role join table to handle authorization for other resources (including what could be an agenda in your app), e.g. can this person access this endpoint if they have the admin role. I probably missed some stuff, lmk how else I can help. On Sunday, June 21, 2015 at 10:36:18 PM UTC-7, Thibaud Clément wrote: > > Hi SD Ruby, > > I am trying to build a Rails app and I am running into road blocks with > "database design". > > The app must allow users to create and share agendas with other users. > > In addition, we must be able to: > > - Display a list of agendas for each user, on his profile > - Display a list of users associated with an agenda, on the agenda's > page > - When sharing an agenda with another user, define a role for this > user, and display the role of this user on the list mentioned right above. > - On a user's profile, in the list of his agendas, we could also > mention his role for each agenda > > I was going to go with a has_and_belongs_to_many association between the > user and the agenda models, like that: > > class User < ActiveRecord::Base > has_and_belongs_to_many :agendasend > class Agenda < ActiveRecord::Base > has_and_belongs_to_many :usersend > > But then I wondered whether this would let me get and display the > @user.agenda.user.role list ofroles on the given agenda page of a given > user. > > And I thought I should probably go with a has_many :through association > instead, such as: > > class User < ActiveRecord::Base > has_many :roles > has_many :agendas, through: :rolesend > class Role < ActiveRecord::Base > belongs_to :user > belongs_to :agendaend > class Agenda < ActiveRecord::Base > has_many :roles > has_many :users, through: :rolesend > > And although I was pretty comfortable about the idea of a user having > several roles (one for each agenda), I am not sure about the idea of an > agenda having several roles (one for each user?). > > Finally, to add to the confusion, I read about the polymorphic association > and thought it could also be a viable solution, if done this way for > instance: > > class Role < ActiveRecord::Base > belongs_to :definition, polymorphic: trueend > class User < ActiveRecord::Base > has_many :roles, as: :definitionend > class Agenda < ActiveRecord::Base > has_many :roles, as: :definitionend > > Does any of the above solutions sound right for the situation? > > *UPDATE*: Doing some research, I stumbled upon this article (from 2012) > explaining that has_many :through was a "smarter" choice than > has_and_belongs_to_many. In my case, I am still not sure about the fact > that an agenda would have many roles. > > *UPDATE 2*: I also asked this question on Stack Overflow and someone in > the comments suggested that a way of solving this would be to go with two > join tables. I tried to implement the following code: > > class User < ActiveRecord::Base > has_many :agendas, through: :jointableend > class Agenda < ActiveRecord::Base > end > class Role < ActiveRecord::Base > end > class Jointable < ActiveRecord::Base > belongs_to :user > belongs_to :agenda > has_many :agendaroles through :jointable2end > class Jointable2 < ActiveRecord::Base > belongs_to :roles > belongs_to :useragendaend > > I am not sure about the syntax though. Am I on the right track? And how > should I define the Agenda and the Role models? > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
