Add non-empty constraint for UserSocialAuth uid

[aleksanb]

Proposed changes

Any empty uids delivered by providers are surely erroneous, and better to have integrity errors than having users start sharing accounts when logging in.

A DB check constraint will catch issues like this one, and ensure that no matter the way a usersocialauth model is created, no empty uids can be inserted.

I'd say this is a bugfix mostly, but a breaking bugfix at that, as existing users of this library might have uid='' in their database by accident. These are real errors that those users will want to fix, and we should mention this upgrade in the changelog as a breaking change.

Types of changes

Please check the type of change your PR introduces:

• Release (new release request)
• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (PEP8, lint, formatting, renaming, etc)
• Refactoring (no functional changes, no api changes)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Build related changes (build process, tests runner, etc)
• Other (please describe):

Checklist

Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask. We're here to
help! This is simply a reminder of what we are going to look for before merging
your code.

• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added documentation to https://github.com/python-social-auth/social-doc

[aleksanb]

Any thoughts on whether this could be accepted?

[nijel]

I think it makes sense, but I'm not sure about splitting the constraint to UserSocialAuth instead of AbstractUserSocialAuth. Also this makes the tests fail.

[aleksanb]

I can move the constraint up to AbstractUserSocialAuth, i'm not familiar with the difference between AbstractUserSocialAuth and UserSocialAuth though.

I'll have a look at the test failure.

[nijel]

I'm not familiar with it either, I'm just curious about splitting the constraint from the field definition.

[stianjensen]

It would probably work as long as the Meta-class of UserSocialAuth is also updated to explicitly subclass AbstractUserSocialAuth.Meta, like this: class Meta(AbstractUserSocialAuth.Meta): (and as long as UserSocialAuth does not get its own definition of constraints in the future that overrides this one – although if that happened, it would be detected by seeing a new migration operation appearing).