User model expansion and decomposition
Closed this issue · 1 comments
s2t2 commented
Per #6 (comment), here are the user attributes collected by the client app during the user registration process:
Consider adding oauth-related attributes. And figure out a way to incorporate the preference-related attributes while balancing needs for flexibility and security.
Consider splitting the User
model into component User
, UserAuth
and UserPreference
models. Maybe something like this:
{
username: "____",
first_name: "____",
last_name: "____",
bio: "_________",
image_url: "_____",
hero_url: "_____",
birth_year: 1975,
professions: ["Student", "Performer", "Instructor"]
auth: { // <--- proposed attributes for the `UserAuth` model
email: "____",
password: "____",
confirmed: true,
oauth: true,
oauth_provider: "Google",
role: "User",
access_level: "Full"
},
preferences: { // <--- proposed attributes for the `UserPreference` model
visible: true,
composers: ["Bach"],
performers: ["Dave Matthews"],
periods: ["Classical", "Contemporary", "Baroque"],
instruments: [{
name: "Guitar",
owned: true,
owned_models: ["Gibson ABC", "Fender Blah"]
}]
}
}
... or maybe something like this instead, with User
, UserProfile
, and UserMusicPref
:
{
username: "____",
email: "____",
password: "____",
confirmed: true,
visible: true,
oauth: true,
oauth_provider: "Google",
role: "User",
access_level: "Full"
profile: { // <--- proposed attributes for the `UserProfile` model
first_name: "____",
last_name: "____",
bio: "_________",
image_url: "_____",
hero_url: "_____",
birth_year: 1975,
professions: ["Student", "Performer", "Instructor"]
},
music_preferences: { // <--- proposed attributes for the `UserMusicPreference` model
composers: ["Bach"],
performers: ["Dave Matthews"],
periods: ["Classical", "Contemporary", "Baroque"],
instruments: [{
name: "Guitar",
owned: true,
owned_models: ["Gibson ABC", "Fender Blah"]
}]
}
}
s2t2 commented
For now I am storing everything except musical preferences / survey responses on the user model, and we can tackle the preferences separately. And we can split the model up later if necessary.