>>> 2) Validate new usernames for case-insensitive uniqueness and filter >>> with case-insensitive queries whenever the username is URL param. > >> def view(request, username, child=None, ...): >> username = username.lower() > > The problem here is that that even if 'Charlie' and 'charlie' cannot > exist as usernames concurrently, 'Charlie' still can if he gets there > first. So if that were the case and I had '/Charlie/' and passed > username.lower() to `widgets = > Widget.objects.get(owner__username=username), it is going to look for > charlie and won't find it. At least I am pretty sure that happened to > me last evening when I was trying this, though it was pretty late...
Ok, but cannot you store owner.username in lowercase from the start? At some point, Charlie wants to create an account (or however you've set it up), and while you have a proper name (Charlie Someone), the username is (invisibly) charlie. If you put in a line on the sign up form or similar stating that the username will be lower case, that shouldn't be confusing. (Eg, wikimedia doesn't bother with case for user accounts on sign up and afterwards. In fact, it always capitalizes the first letter, even if the account would 'root', which is typically an all lower-case account.) For user friendliness, the username should be invisible to the user. The fact that you allow it in the URL is ok, but should otherwise still be invisible (You could even choose to redirect to an all lower- case URL). Though I fear I'm simply misunderstanding your problem (or missing some unknowns), so all my suggestions may be of not much use anyway! Evert --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
