Add natural keys to contrib.auth.User and Group models

[Juarez Bochi]

Permissions and content types already have natural keys. Having natural keys for User and Group models could be useful too.

[erikrose]

Going out on a limb and assigning this to 1.3 so it gets some notice. I'd be happy to write tests if needed.

[Łukasz Rekucki]

Sounds reasonable. I have no idea if this needs tests so leaving for someone else to review.

[Cesar Canassa]

I am using his patch right now, so I can confirm that it works.

[Paul McMillan]

At the very least this patch still needs tests and documentation before it's RFC. I'm agnostic about the actual functionality.

[Gabriel Hurley]

Agreed, needs tests and docs, but otherwise the patch seems fine to me.

[Juarez Bochi]

I have added two small patches for tests and documentation. I am willing to improve/modify them if needed.

[Łukasz Rekucki]

Would be good, if you can join all three patches into one. It's easier to review that way.

[Juarez Bochi]

As per lrekucki suggestion, I have combined the three files into 139414.diff

[diogobaeder]

This feature would be greatly useful for me, too; I also confirm that the patch works. Please apply it as soon as convenient.

[Flaviu Simihaian]

13914.diff was not done at the root. I attached 13914.2.diff which updated the patch and verified the tests.

[Gabriel Hurley]

I know we're extremely late in the 1.3 cycle here, but it would be really nice to see this slip its way in rather than having to wait for another entire release cycle.

[Russell Keith-Magee]

Yes, we are *very* late in the cycle; this is something that has fairly major consequences to serialization, so it needs to be considered carefully, and shouldn't be committed between RC and final.

I'm also not entirely convinced that this is a good idea, either -- it has some fairly major consequences to existing serializations. I think it needs more discussion before it gets committed.

[Gabriel Hurley]

mmmm... I hadn't previously been aware that the natural key deserialization happening in core.serializers.python.Deserializer wasn't written to fall back completely cleanly should it encounter a "mixed" set of serialized objects where it might be expecting a natural key but got a PK instead. I can see where this gets complicated now that I've taken a close read of the code for how it works. Russ is right, as is par for the course. ;-)

[Jacob]

Milestone 1.4 deleted

[marcin.tustin@…]

I would very much like to see this added (even if only in some optional way). Is there a way to help progress this?

[Aymeric Augustin]

Since the patch doesn't apply to trunk, you could update it for the latest SVN revision.

You could also investigate the issues Russell and Gabriel hint at in commets 13 and 14, and how to mitigate them. Would this change would break all existing user and group fixtures?

[Aymeric Augustin]

I'm going to accept this ticket with one condition: check that existing fixtures (without natural keys) still load properly after the change. This should be tested.

[Juarez Bochi]

I have checked that data dumped without natural keys can still be loaded after this change. The tests were included in the new diff.

[Claude Paroz]

Looks nice for me, thanks.

[Chris Wilson]

Users can retrofit this, without modifying Django source, using the following monkey patch:

from django.contrib.auth import models as auth_models
from django.db import models as db_models
class GroupManagerWithNaturalKey(db_models.Manager):
    def get_by_natural_key(self, name):
        return self.get(name=name)
auth_models.Group.objects = GroupManagerWithNaturalKey()
def group_natural_key(self):
    return (self.name)
auth_models.Group.natural_key = group_natural_key

[Simon Charette]

Replying to gcc:

Users can retrofit this, without modifying Django source, using the following monkey patch:

from django.contrib.auth import models as auth_models
from django.db import models as db_models
class GroupManagerWithNaturalKey(db_models.Manager):
    def get_by_natural_key(self, name):
        return self.get(name=name)
auth_models.Group.objects = GroupManagerWithNaturalKey()
def group_natural_key(self):
    return (self.name)
auth_models.Group.natural_key = group_natural_key

I think you might want to return a tuple in group_natural_key .

def group_natural_key(self):
    return (self.name,)

[Jannis Leidel]

In [17429]:

Fixed #13914 -- Added natural keys to User and Group models in auth contrib app. Thanks, jbochi and closedbracket.

[Walter Doekes]

Backport of natural group keys for older Django

[Walter Doekes]

Replying to gcc:

Users can retrofit this, without modifying Django source, using the following monkey patch:

That fix was incomplete.

If you want to load Groups without PKs, like this:

    <object model="auth.group">
        <field type="CharField" name="name">Billing and invoicing</field>
        <field to="auth.permission" name="permissions" rel="ManyToManyRel">
            <object><natural>add_backupinfo</natural><natural>backupinfo</natural><natural>backupinfo</natural></object>
            <object><natural>change_backupinfo</natural><natural>backupinfo</natural><natural>backupinfo</natural></object>
    ...

Then you'll also need this feature:

New in Django 1.7.
Deserialization of objects with no primary key will always check
whether the model’s manager has a get_by_natural_key() method and
if so, use it to populate the deserialized object’s primary key.

The attached file django_13914_group_natural_keys.py does a monkey patch to introduce the required functionality.

Tested on Django 1.3.7.

Cheers and thanks for Django,
Walter Doekes
OSSO B.V.