Re: Negative User ID's

On Oct 26, 2016 5:58 PM, "Mike Dewhirst" <miked@dewhirst.com.au> wrote:
>
> On 27/10/2016 9:57 AM, michael@zanyblue.com wrote:
>>
>> Hi,
>>
>> The Django contrib User model is used to create accounts in Django applications.  I would like to keep accounts associated with real people separate from accounts created for mailing list and/or service accounts.  I was planning on using negative ID's for these accounts and can't see any issue with this from a Django or DB point of view (would need to create and manage my own sequence for this).
>>
>> Can anyone see any issue with this?
>
>
> Yes. It requires you (or those who maintain the application after you) to manage something which the DBMS should manage "under the covers". If this was my application I would be designing it with as few subtleties as possible for the next person to support after I leave the project.
>

+1

I would also add that the easiest way to manage such a situation would be to create a user profile in a separate table for any account that has a real person attached to it.

There would be a OneToOne relationship between the user profile and the User model. A simple join would pull all of the User objects that have attached profiles, giving you the list of accounts attached to real people.

Django has an example of doing exactly this as a method of extending the User model:

https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#extending-the-existing-user-model

Work with the database (separate tables and joins), not against it (weird negative indexing with no direct DB control).

If you're early on in development still, I would also strongly recommend that you create a custom user model rather than relying on the included User model. If you need to make changes to that model later, it is a royal pain to create a custom one after your site is in production. Do this even if you aren't changing anything right now. It is good practice and recommended by Django:

https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#substituting-a-custom-user-model

That page doesn't specifically have the recommendation, but you can see evidence of it in the warnings posted in that section. Note that you should plan on AUTH_USER_MODEL not ever changing during your project life cycle, meaning that a custom user model will better future-proof your project in the event your requirements change (allow longer user names, making email required, etc.).

-James

--
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+unsubscribe@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/CA%2Be%2BciXkUgGn2jgqws5cnMVQ3E%2BqrJT%3D0agkW35R7r_%2BbJwrdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.