I’m following the Programming Phoenix 1.4 beta ebook, and would now like to “extend” the User model, and wondering what are the options and the best way forward.
If I am doing a blog site, I would like to add fields to the User such as Bio, Avatar, etc. and I think these should not be in the User model, but in a new model called Member, which has a has_one relationship with User (i.e. in OOP parlance, Member extends/‘is a’ User). Similarly, I would create an Admin model, which has a has_one relationship with User. Therefore User will have two has_many relationships with Admin and Member. The User model will still have a has_one relationship with Credentials for authentication.
I have also seen elsewhere (before contexts were introduced in 1.3) people creating a model Role and seeding it with specific role types.
Which approach is better? I think the former is, but I think that might be because of my OOP mindset.
Thanks.
I think it depends on what you are storing in these other models. How is member different from user? How are they both different from Admin? Can you provide some more information?
Yes, of course. User would just have a name and username field. Member would have additional fields like bio and an avatar (string field to store a link to a pic stored on S3 storage)
and Admin (or Staffof the website) could have contactable details for users to get in touch with.
Admin would also have access (i.e. permissable actions in the controllers) to, for example, delete a Member
My personal opinion here is that having 3 tables to represent Users and their permission status is overly complex.
Something to remember is that Schema is not a Model.
It’s quite possible to have User schema, an Admin schema, and Member schema which are all backed by the same database table. They just map to different columns sets - which might overlap.
I’m not saying that’s what you should do, but it’s a point worth getting your head round.
The design of your tables really comes down to how “normalised” you want your database. Structuring your domain objects shouldn’t really be dictated by your database.
A good question to highlight this is, can a User be an Admin, without being a Member?
Or can a Member exist without being a User?
Admin and Member are both User in the OOP model sense. User is the base model as it were, and it is at this level that authentication is tested (User has a has_one relationship with Credentials, therefore, Admin and Member will too).
I guess I have schema and model muddled up together. I like the idea that schemas can just map to different column sets
