Negative User ID's

[mic...@zanyblue.com]

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?

Take care,
Michael.

[Mike Dewhirst]

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.

>
> Take care,
> Michael.
> --
> 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
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@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/fe7444f4-eb17-49d2-b553-3f3d8004b034%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/fe7444f4-eb17-49d2-b553-3f3d8004b034%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[James Schneider]

On Oct 26, 2016 5:58 PM, "Mike Dewhirst" <mi...@dewhirst.com.au> wrote:
>
> On 27/10/2016 9:57 AM, mic...@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

[Nate Granatir]

Or why not just assign certain Users to certain Groups? That seems like a much more clean and simple way of handling the problem. You'd be able to easily filter either set of users, and it would require very little custom code. Plus, doing something like assigning negative IDs disguises what you're actually trying to accomplish, whereas auto-assigning certain users, to, say, a group called "Service Accounts", is perfectly clear to anyone looking at the code.

Nate

[mic...@zanyblue.com]

Hi,

The normal user table will be synced from another application that doesn't allow non-real users.  To support future integration, I need to ID's to be common across the two apps.  The positive ID range is, in a sense, not available at this time.  My real question was "is there any issue using negative IDs".

Take care,
Michael.

[Javier Guerra Giraldez]

On 4 November 2016 at 17:17, <mic...@zanyblue.com> wrote:

To support future integration, I need to ID's to be common across the two apps.

that's what foreign keys are for

--

Javier

[Vinicius Assef]

On 4 November 2016 at 15:17, <mic...@zanyblue.com> wrote:
> My real question was "is there any issue using
> negative IDs".

I'd check it with the database backend. I mean, read its documentation.

And make a double check on the django side. Maybe contacting one of
core developers.

[mic...@zanyblue.com]

Unfortunately, the apps are currently in different DB's.

[Javier Guerra Giraldez]

even so, a foreign key field is the answer. i see three different
ways to do it:

- on the app. just add an indexed (unique) field, with the id on the
other DB table

- with a 'ghotst' table, that is actually related to your Users model
and some model methods to manage it

- managed by the database itself. not sure about other RDBMS, but
postgre at least have some serious "foreign data wrapper" capabilities
that make many kinds of other things look like regular tables.


[1]: https://wiki.postgresql.org/wiki/Foreign_data_wrappers



--
Javier