On 20/05/2018 1:45 PM, Daniel Germano Travieso wrote:
There is no really definitive approach to handle this, and you could
do it either way.
Either option works, but for a philosofical point of view, if there is
no significant difference between the user types, the first approach I
tend to believe is the most logical one.
However, as a optimal approach, to think on all possible overheads you
may encounter on your system, I believe the second option is best, as
it isolates authentication methods to a specific and stablished module
provided by django, avoiding you the hassle of maybe having to
override user-specific methods.
On my projects I tend to lean towards User + Profile approach.
On the point of view of performance, the User + Profile approach has
de disadvantage of requireing a database join in order to retrieve
user-specific information.
The official django doc has a view on this very subject
https://docs.djangoproject.com/en/2.0/topics/auth/customizing/#specifying-a-custom-user-model
:
" *Model design considerations*
Think carefully before handling information not directly related to
authentication in your custom user model.
It may be better to store app-specific user information in a model
that has a relation with the user model. That allows each app to
specify its own user data requirements without risking conflicts with
other apps. On the other hand, queries to retrieve this related
information will involve a database join, which may have an effect on
performance."
I think that is a good start and it certainly guides my design. In my
overall approach I try and ignore performance and instead bend over
backwards to reflect the real-world relationships. I really don't care
about extra joins until performance is proven to be inadequate.
I have been told often enough that performance problems are the best
problems to have because you can generally throw inexpensive hardware
resources at them until they go away. Much better than the software
being too difficult to change as the business evolves.
For example, if a user has a role the role should apply to the user not
to the profile. Putting the role into a 1:1 profile prevents the user
from having more than one role. In real life people can multi-task.
I have adopted the Django auth group system as role. It lets me keep
profile data in profile and roles with permissions in groups. I also
have a bunch of is_author(), is_editor(), is_consumer() methods in view
utils so I can do non-permission related stuff as well.
Mike
Hope it helps!
On Wednesday, May 16, 2018 at 11:53:58 AM UTC-3, Bill Torcaso wrote:
I inherited a system which has one User model, and a Profile model
that is 1-to-1 with User. The type-of-user information is carried
in a required "role" property in the Profile. I think that is a
well-established approach.
I am curious to hear what people think of the tradeoffs between
(User + Profile) and (User-base-class + subclasses).
On Tuesday, May 15, 2018 at 12:41:50 PM UTC-4, Vijay Khemlani wrote:
I would make a UserType table and have a foreign key from your
user model to it, or maybe just have an enumerated type in
your user model depending on how much custom logic there is to
each user type.
On Tue, May 15, 2018 at 11:50 AM Frankline <frao...@gmail.com>
wrote:
Hello Everyone,
I am developing an API based on Django Rest Framework
<http://www.django-rest-framework.org/>. Currently I have
4 user types i.e. Buyer, Merchant, Insurer, and Admin.
The system I'm developing has an *API endpoint* and a
*Dashboard* view.
Each of the above user types have different fields and may
need to login to the system at one point, so having one
user model is the best way to go. Note that, a user can
only be of one type.
However, only the merchant will be actively using the API
endpoint.
My question is then, how will I be able to manage the
different user types in the system?
My current options are:
1.
1. classBaseUser(AbstractBaseUser):
2. ...
3.
4. classBuyer(BaseUser):
5. ...
6.
1. classMerchant(BaseUser):
2. ...
3.
1. classInsurer(BaseUser):
2. ...
2.
1. fromdjango.db importmodels
2. fromdjango.contrib.auth.models importUser
3.
4. classBuyer(models.Model):
5. user =models.OneToOneField(User)
6.
7. classMerchant(models.Model):
8. user =models.OneToOneField(User)
9.
1. classInsurer(models.Model):
2. user =models.OneToOneField(User)
1. ...
Which is the most optimal way of handling this?
1.
--
You received this message because you are subscribed to
the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to
django...@googlegroups.com.
Visit this group at
https://groups.google.com/group/django-users
<https://groups.google.com/group/django-users>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAEAUGdVwB_RrOP_s9Oj5fe6AoOXJ9qpPLUKpE%2BbAO_NLGMRn6g%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CAEAUGdVwB_RrOP_s9Oj5fe6AoOXJ9qpPLUKpE%2BbAO_NLGMRn6g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/57553c72-81d0-438b-8964-080eb539a986%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/57553c72-81d0-438b-8964-080eb539a986%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/14476f5c-d673-897c-6023-0955026d71f6%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
