Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Lars Wettmann
15,376 PointsBest practise for different types of users
I'm trying to build a Django project with different kind of users and profile pages. There are "Customers" and "Professionals". I thought I'd have an abstract model with a one-to-one field to the Django user model for a generic 'UserProfile' with common info for all users. Then I'd have two different models for "Customers" and "Professionals". Users can be either none of the two (if they just signed up), one, or both (If they are professional and customers of other professionals).
2 problems: a) I have no clue how to access the user's information for the class based profile view. b) bigger problem: Everytime Django accesses a user, it uses slow 'join' commands and I have to have another query for all the customer or professional data. That's slow when the project scales up. I thought I could solve that with a field in the Django user "is_professional" and "is_customer", so I only query the specific Customer/Professional model once needed.
But it seems so complicated. Any ideas or resources on how to solve such a scenario? I cannot be the first one and google is not very helpful to me.
Thanks in advance.
1 Answer
Chris Freeman
Treehouse Moderator 68,426 PointsConsider what the code needs to do if a user upgrades/downgrades between the subscription levels you have. Will the code create and migrate the models as necessary?
At first some hierarchy seems desirable, but if performance is critical, a flatter approach might be better. You might want to consider making one flat model with all the aspects of common, customer, and professional. Then use, as you mentioned, model attributes is_customer and is_professional as checks within the class methods to access or modify restricted content.
You might also wish to look into using Prefetch() along with prefetch_related to limit excessive DB querying.
Lars Wettmann
15,376 PointsLars Wettmann
15,376 PointsThanks, Chris. That sounds like a much better approach.
What are the differences between using model attributes vs django permission groups to access or modify restricted content in your opinion?
I'll definitely look more deeply into prefetching. Good one!