I've got plenty ideas for approaching issue of enforcing case insensitive uniqueness of email on DB level while still maintaining original case of name part. They differ in level of hackiness or amount of change needed, but if somebody has to make fool of himself proposing them, please accept my humble sacrifice. ;)
1. Create extra model unique field containing lowercase email or some hash of it - this looks very hacky thing to do that would give plenty of people "ahaaa!" moment when they run into problems... and they won't be pleased aftherwards. 2. Add ci_unique option to the ORM fields - this will need changes in the ORM's and migrations implementation, plus note in docs that it won't fly on certain DB's and other means would be used. 3. Add "case_sensitive=True" kwarg to create_unique for use in migrations that would make created unique constraint case insensitive. Then, add note to the user auth doc's about gotcha with case sensitivity and provide extra documentation with examples for solving this problem via that function and custom migrations. My favorite because it appears to be least invasive towards existing codebase, may be reauseable for other custom use-aces, but may be considered secret knowledge by people only just beginning with Django if not presented correctly in docs. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/e28e8809-3d42-4f1a-b288-e6e3bc832552%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
