Added an optional USER_SESSIONS_USER_TO_FIELD setting

[ydaniv]

Allowing configuration of Session.user.to_field.

My use case: I have a field uuid on my Account model which is the actual field I'd like to reference. I can't make that field primary yet since it will break other parts of Django or other packages that expect Account.pk to be an integer.

[coveralls]

Coverage remained the same when pulling 9135a5e on COMMOLOGIC:master into 105ec5c on Bouke:master.

[ydaniv]

Running a South automatic schemamigration claims nothing has changed.

[coveralls]

Coverage remained the same when pulling ab09c9b on COMMOLOGIC:master into 105ec5c on Bouke:master.

[ydaniv]

Hmmm... South lied ):
Probably because I'm getting the field's name dynamically from settings.
Fixing...

[ydaniv]

This gets tricky in case the field's type is changed ):
Closing this and going back to the lab.
Will be happy to know if this is at all appropriate and likely to be considered for merging.

[Bouke]

Yes, changing the type down the project will probably have a large impact. So why do you wan't to continue using another field, which is not the primary key, while keeping the actual the primary key in place? You could use the actual primary key as well.

[ydaniv]

The problem is that some packages, even Django itself, still consider the User's primary key to be an integer.
But I'm trying now to go down that path once again and see if I can pull it off with latest versions.

So now the initial migration of user_sessions is problematic since it states that the User's primary key is a django.db.models.fields.AutoField which translates to an integer type.

Seems that overriding it, e.g. with uuidfield.fields.UUIDField, does the trick.

Is there a way we can at least make that part dynamic?

[Bouke]

You'd probably have to look into making this part dynamic. In order me to merge this pull request, your changes should not include extra configuration settings. I think it should work when you set the User's primary key to the UUIDField and than the initial migration should pick-up on this. So that would require inspecting the type of the primary key.

For your other problem with Django itself, you could have a look into overriding the migrations that are created. Or patch the models altogether in your code.

[ydaniv]

You'd probably have to look into making this part dynamic

Yes, that is the part I was asking about:

Is there a way we can at least make that part dynamic?

I don't think there's a way making this dynamic, unless it's settings option.

My only way out of this now is patching this in my own fork.

If it's something you're willing to consider, please let me know and I'll work on a new PR.

Thanks a million!

[Bouke]

I think it would work in the migrations, if you changed the relevant part to this:

        User._meta.pk.attname: (
            '%s.%s' % (User._meta.pk.__class__.__module__, User._meta.pk.__class__.__name__), [],
            {'primary_key': 'True',
            'db_column': "'%s'" % User._meta.pk.column}
        ),

Can you try to get this to work?

[ydaniv]

I'll give it a try, thanks!

Another thing I came across was that when the sessions backend is attempting to JSON-serialize the session it's breaking because the session key, i.e. the user id, isn't serializable since it's a UUID object instance.

Trying to find now the cleanest way to get it cast to a string/unicode on serialization. Any idea?

[ydaniv]

Looks like it Django isn't ready yet for this, see here. And the serialization issue is all over the web without a reasonable solution in sight.

I have an idea on a different approach which I'll open in a separate thread.

Thanks for all your help!