In the example given, it's a relationship between users and organizations. the join table (memberships) would have a field (column) named user_id and column named organization_id. All of the tables, as is rails convention, would have a ID column which is the primary key.
The relationship between organization and blogs would be one to many (organizations would have many, blogs would belong to organization). The blog subscription table would act in the same way as the membership table above, only it joins blogs and users. User would have many blogs through BlogSubscription and Blog would have many users through BlogSubscription. As far as login and authentication is concerned, I would consider the devise gem. It can be added later, as the above post suggests, but that can be a little more difficult. For example, I once rolled my own authentication and later decided to implement devise. Devise sets up a migration when it's installed. In my case, I was setting up Devise on the User table. It tried to add an email column which I already had, so the entire migration raised an exception. Unfortunately, the migration it creates is a set of methods and the code that adds the email column was buried in a method. The point of this is that if you are going to use Devise, it might be better to start up front with it. I recommend it because, in addition to basic authentication, it adds capabilities such as confirming an email address when a new user sets up in the system, locking the account after a given number of unsuccessful attempts, etc. These tend to be features an app like yours uses and it requires almost no coding with devise. With respect to roles, it depends on how involved your roles are. I would leave this to a later iteration as one of the posts above suggests. There's also a gem for this that is popular (cancan). I have mixed feelings on it. It's heavily controller-based. hope this helps, mike On Jan 17, 8:24 am, Mohamad El-Husseini <[email protected]> wrote: > @Jordan, thank you for the explanation. I'm having a hard time seeing what > the relationships model looks like: id, user_id, blog_id, > relationship_type_id? In that, the relationship_type_id decides if the > relationship is a user or an editor? > > Blog > belongs_to organization > belongs_to editor through relationships > belongs_to subscriber through relationships > > I also haven't thought about a privileges table yet, so I'm unsure what > that class would look like. > > @Aline, it's funny, I always approach a new app by creating a user model, > then login and authentication. Interesting approach. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
