this is basically a theoretical question.
What do you think is better for a normal rails app with users:
1)Create a Profile model where to put resume, images, links etc...
2)Put all the data in the user model.
The first choice maybe is cleaner but you have to load 2 models from the db, so maybe slower.
Thanks in advance.
I normally have a single User model. If I have unrelated resources that may deserve an associated model, than I create one for them.
For example, for me the Resume (assuming is not a single field) may deserve a dedicated Resume model, with a one-to-one association to User.
On the view, I normally create an /account resource that internally displays the account and provides the show, edit and update actions to view the account or update it.
The more models you have, the more your architecture will become complicated. So unless you have the need to split the fields out of the User model, I would keep them inside the model.
When you start to have several fields that may require a prefix, such as resume_title, resume_body, resume_created_at inside the User model, that's a good indication that you probably need a separate Resume model associated to the User.
Related
If I want to build a Rails app that has two different types of users, let's say one type is called players and the other one is owners, what is the best and most efficient approach to modeling the app?
Things to take into account:
There should only be one Login, but different Registration forms that Owners/Players can use.
Owners can have access to a control panel but Players cannot.
Owners cannot share any of Players capabilities, but both need to be able to perform Login/Registration.
I am not using Devise, so please do not suggest it.
Different Approaches I've considered:
Using cancancan gem, but it does not really seem to meet my needs in the sense that I am not looking to create a user/admin hierarchical approach but rather a if you're a Player, then you can see these pages and perform these actions but Owners cannot and vice versa. Almost like splitting the app in two. cancancan seems that it would treat Owners as "Players with extra privileges", not different privileges entirely.
Creating separate models with separate login and registration forms, which seems like a disaster waiting to happen. One small mixup between a Players table and the Owners table, especially with the primary keys, and that will be a world of trouble where people could end up logging in to the wrong accounts.
Creating a polymorphic or has_one relation toward an Account model, which so far, seems like the best way to probably go about it. If I created a polymorphic Account model, I can store different types of Players/Owners, but how could I compare login credentials against all types?
I had been trying to find something on this matter regarding how to map this out and was surprised to not find an information on how to do this without using Devise. If anyone has any good links they can point me to that also address this matter (without Devise), please leave them in your answer! Thanks.
I'd suggest one User class with a type attribute that determines whether the user is a Player or an Owner (single table inheritance). This way you keep the registration logic in one place but can customize the forms depending on the user's class.
There must be alternatives to cancancan that help with what you want to do, or you can implement helpers yourself:
def can_access_control_panel?
current_user.is_a?(Owner)
end
You have to have a way to separate one user from another. One way is to add an attribute to the User table so you can call current_user.role and it will return "owner" or return "player".
I have used Pundit gem in the past. It lets you define which controller actions the current user is allowed to access. So as you create resources for your application, you can add a policy that specifies who is allowed to that given resource. This is the repo to the application.
This answer might help you.
In a rails application. If you have a User model and a post model and a user can post X number of times according to a plan.
Can I just modify the User object and add a plan_id to my user object or is it better to generate a new model called plan and associate it to a user?
It depends on what informations you want to store for the plan.
In my opinion, you should add a Plan model and add an association.
In that case, you can store all important informations about the plan itself in a Plan and use it to show them on the pricing page, as well.
But i guess, there is no "right" or "wrong" answer, just favorites. :)
There's no good way to answer this without knowing specifics or the future.
Might users end up having multiple plans?
How frequently are the plans required?
A "user" is not a "plan". A user has a plan. There should be a plan model; how it is stored is a separate issue. It may not be worth over-thinking at this point, either.
I currently have a "user model", which is managed by the gem devise. Right now, that model has only the most basic information (first name, last name, email, password).
Now I am wondering wether I should add additional user fields as an additional, associated model (e.g. named "userprofile") or just add the additional fields to the existing "user" model (profile picture, years of experience, description about the teacher etc.). What is the common practice?
I am looking forward your help.
Best regards,
Alex
When you call current_user (or any devise helper method per se), it retrieves all the fields from the database for that user record, whether or not you need 'em. So, it's better to have as lesser fields in the devise's user model as you can. If you want to create a user profile with additional fields, better create a new associated model.
In general, add those kinds of "simple" attributes directly to the User model (i.e. years of experience, description, etc). As you add more complicated information about a user (e.g. job history), or if you have a significant amount of these attributes such that it might start impacting performance, you may want to start adding associated models. But otherwise it's probably not worth the added complexity.
been kicking this one about for a while now, and would like to get someone who knows rails to test my theory (I'm new to Rails).
In my (simplified) scenario, I want to manage a list of Users, some of which are, for example, "paid" users, some are "free" users etc, and there is a straight "isa" relationship. i.e. a paid user isa user, a free user isa user etc
To reduce redundancy and to keep it semantically correct, I want to manage all the users in one table and use a foreign-key back to the correct "type" of user, so I can create a role of the correct type. e.g. I would instantiate a User, get the id and store this in the user of correct type e.g. "PaidUser" in the "user_id" foreign-key. This gives me the ability to store specific metadata I want to store against them, and I don't have to have one table ("users") with every field for every type of user.
This sort of feels like a confusion of roles and types of users. My question is, is using the approach above going to make life difficult? Is there an accepted approach to this in Rails that I'm missing? I'm using Devise and have removed all routes except for /users/ thinking I would pass a "type" as an argument, and use that type to create the corresponding "real" type of record at the same time as the user. Is this bad practice too?
Thanks in advance
What you're doing sounds fine, but to be honest unless you have a lot of these different properties between user types I would just put them all in the same table. It's not really a big deal to have a couple of blank columns here and there, especially when it saves you from having to do a whole load of difficult stuff. If this starts to seem unwieldy then you can worry about what to do then - it would still be easy to change. You could even then potentially use Single Table Inheritance to give all the different user types their own class that inherits from the base User class, which is where you take care of all the authentication etc.
If you immediately go with something more complex then it will be much harder to unravel if it turns out to be wrong than if you start with something simple. If you go with the multi-table approach then make sure you name them sensibly. I would go with PaidUserProfile etc.
I'm making an app with Rails that, among other things, allows certain types of professionals to create an online profile. So there is an 'association' between the User and Profile model. I created the Profile model so that I can basically restrict the User model to name and registration information, and keep profile information elsewhere (i.e. 'normalize' the db as I think it's called)
However, these profiles (as is often the case, on LinkedIn, for example) contain a lot of information. For example, there will be a section for Work Experience that sometimes looks like this, where a user can add many different work experiences.
and then something similar for education
And many other different types profile information. Note also, that the ability to add to and edit these discrete categories takes place in separate forms. I can add to my work experience without touching education.
My question is, should I try to store all of this information in my Profile model? Or, would you, for example, create a WorkExperience model and do something like Profile :has_many work_experiences? and something similar with EducationExperience, or is there even another way to do it?
One of my concerns is queries on the DB. For example, in terms of performance, is there going to be much of a difference if, in the show action of the Profile controller, I do queries for WorkExperience.all, Education.all rather than storing all the information in the Profile model?. Another concern is just general code organization for profiles that can become quite large.
You'll have the cleanest code (and decent performance) by splitting out something like Experience (which will belong_to Profile), along with a type column that determines whether it's "work" experience, "education" experience, etc. That's the approach I would take, unless the different types of experience have vastly different columns.