Re: Case-insensitive email as username

[Carl Meyer]

On 11/24/2015 04:33 AM, Aymeric Augustin wrote:
> 2015-11-23 23:52 GMT+01:00 Carl Meyer  >:
> 
> I've implemented the CITEXT-based solution a couple times; I think for a
> PostgreSQL-based project it's the preferable option overall.
> 
> Perhaps we should add native support in contrib.postgres?

I'm in favor. I think it's likely as common a need (if not more common)
as the other utilities provided there -- even if most people who need it
are currently probably using an ORM-level or form-level instead of
db-level solution.

> I'm forseeing a small difficulty in terms of API. This is a behavior I'd
> like
> to "mix in" to some fields but I can't say if that will be easy to
> implement.
> 
> The general ideas would be:
> 
> # A mixin
> 
> class CITextField(TextField):
> # ...
> 
> # Case-insensitive versions of some built-in Django default fields
> # (if we consider that makes sense)
> 
> class CIEmailField(CITextField, EmailField):
> pass
> 
> # The possibility for users to make custom fields case insensitive
> 
> class CITagField(CITextField, TagField):
> pass

Here's the entire implementation of my CiEmailField:

class CiEmailField(models.EmailField):
"""An EmailField that uses the CITEXT Postgres column type."""
def db_type(self, connection):
return 'CITEXT'

So I think that's quite amenable to a mixin implementation.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5654BEA9.3080503%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Case-insensitive email as username

[Chris Foresman]

We usually just handle this with a custom serializer (or form) field that 
converts all input to lowercase. That way we don't have to change any 
lookups or anything; all emails that come in to the system are already 
lowercase. Of course, that doesn't preserve what users enter but IME 
anything uppercase is just a fault of using the wrong text box on iOS or 
Android.



On Tuesday, November 24, 2015 at 5:33:54 AM UTC-6, Aymeric Augustin wrote:
>
> 2015-11-23 23:52 GMT+01:00 Carl Meyer :
>
> I've implemented the CITEXT-based solution a couple times; I think for a
>> PostgreSQL-based project it's the preferable option overall.
>>
>
> Perhaps we should add native support in contrib.postgres?
>
> I'm forseeing a small difficulty in terms of API. This is a behavior I'd 
> like
> to "mix in" to some fields but I can't say if that will be easy to 
> implement.
>
> The general ideas would be:
>
> # A mixin
>
> class CITextField(TextField):
> # ...
>
> # Case-insensitive versions of some built-in Django default fields
> # (if we consider that makes sense)
>
> class CIEmailField(CITextField, EmailField):
> pass
>
> # The possibility for users to make custom fields case insensitive
>
> class CITagField(CITextField, TagField):
> pass
>
> -- 
> Aymeric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72d064df-7599-4111-994a-d338dc81e7a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Case-insensitive email as username

[Aymeric Augustin]

2015-11-23 23:52 GMT+01:00 Carl Meyer :

I've implemented the CITEXT-based solution a couple times; I think for a
> PostgreSQL-based project it's the preferable option overall.
>

Perhaps we should add native support in contrib.postgres?

I'm forseeing a small difficulty in terms of API. This is a behavior I'd
like
to "mix in" to some fields but I can't say if that will be easy to
implement.

The general ideas would be:

# A mixin

class CITextField(TextField):
# ...

# Case-insensitive versions of some built-in Django default fields
# (if we consider that makes sense)

class CIEmailField(CITextField, EmailField):
pass

# The possibility for users to make custom fields case insensitive

class CITagField(CITextField, TagField):
pass

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mW60wZcJ-6ahReqNAf4rDN%2BV5dQ%3Dahn%3Dh3Oz3X4uz81pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Case-insensitive email as username

[Podrigal, Aron]

Why not creating the index as LOWER(email) and do the lookup as LOWER?
On Nov 23, 2015 6:18 PM, "Carl Meyer"  wrote:

> On 11/23/2015 03:52 PM, Carl Meyer wrote:
> ...
> > I suppose the best we could do to ease this would be to add a
> > CreateExtension migration operation in contrib.postgres that, if lacking
> > super-user permissions, simply errors out and tells you what SQL you
> > need to run manually as a super-user?
>
> ...and now that I look, it appears we already have the `CreateExtension`
> operation :-) It doesn't appear to do anything special to handle the
> permissions problem. Maybe there's not much useful that can be done.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/56539EB1.7060802%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yiBge_SxmXUkTBB5U75oXoFmDo2RO4rPh707_ZZE9gbLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Case-insensitive email as username

[Carl Meyer]

On 11/23/2015 03:52 PM, Carl Meyer wrote:
...
> I suppose the best we could do to ease this would be to add a
> CreateExtension migration operation in contrib.postgres that, if lacking
> super-user permissions, simply errors out and tells you what SQL you
> need to run manually as a super-user?

...and now that I look, it appears we already have the `CreateExtension`
operation :-) It doesn't appear to do anything special to handle the
permissions problem. Maybe there's not much useful that can be done.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56539EB1.7060802%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Case-insensitive email as username

[Carl Meyer]

Hi Aymeric,

On 11/22/2015 11:56 AM, Aymeric Augustin wrote:
> I spent a good part of today implementing what must be the most common
> scenario for custom user models: case-insensitive email as username.
> (Yes. This horse has been beaten to death. Multiple times.)
> 
> Since it was the first time I implemented a custom user model from
> scratch by myself, I’d like to share my experience in case that’s useful
> to others. Do you think there’s a better solution? Do you have concrete
> ideas for improving Django in this area?
> 
> The main alternative I’m aware of is a custom email field based on
> PostgreSQL’s citext type. Perhaps I’ll try that next time. Anyway,
> here’s what I did this time.

I've implemented the CITEXT-based solution a couple times; I think for a
PostgreSQL-based project it's the preferable option overall.

The main complexity is just in adding a dependency on a Postgres
extension, which is unfortunately non-trivial in general -- you can't
easily just stick "CREATE EXTENSION" in a migration since creating the
extension requires database super-user privileges, which the Django db
user may not have. I usually just punt by documenting that the project
requires you to set up you database with the extension installed.

I suppose the best we could do to ease this would be to add a
CreateExtension migration operation in contrib.postgres that, if lacking
super-user permissions, simply errors out and tells you what SQL you
need to run manually as a super-user?

I also had to add a connection_created handler to register a conversion
to unicode for CITEXT fields, as psycopg2 otherwise returned them as str
(this was Python 2 - that issue may not exist in Python 3). This issue
would be easy for Django to fix if we want to bake in any level of
CITEXT support in contrib.postgres.

Once you clear those initial hurdles, the CITEXT solution is smooth
sailing. All the rest of the issues covered in your post go away
entirely, since the database handles all the case-management (original
case preserved but ignored in lookups and indexes) internally, and the
ORM doesn't need to know anything about it.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/565398CB.8060706%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature