Django: Effectuer des recherches insensibles à la casse par défaut

Question

J'ai besoin d'effectuer des requêtes insensibles à la casse sur username par défaut lorsque vous utilisez le framework Django Auth.

J'ai essayé la résolution du problème en écrivant une sous-classe personnalisée de Queryset et la substitution de la méthode de _filter_or_exclude et en utilisant ensuite que sous-classe dans un gestionnaire personnalisé pour le modèle utilisateur -

from django.db.models import Manager
from django.db.models.query import QuerySet
from django.contrib.auth.models import UserManager

class MyQuerySet(QuerySet):
    def _filter_or_exclude(self, negate, *args, **kwargs):
        if 'username' in kwargs:
            kwargs['username__iexact'] = kwargs['username']
            del kwargs['username']
        return super(MyQuerySet, self)._filter_or_exclude(negate, *args, **kwargs)

class MyUserManager(UserManager):
    def get_query_set(self):
        return MyQuerySet(self.model)

User.objects = MyUserManager()

Mais cette approche ne fonctionne pas et je me fais une erreur bizarre quand je essayez de faire User.objects.get(username='Foo').

Toute aide serait appréciée.

Mise à jour :. Je suis notamment l'erreur exacte que je reçois

/usr/lib/python2.5/site-packages/django/db/models/query.py in get(self, *args, **kwargs)
    295         keyword arguments.
    296         """
--> 297         clone = self.filter(*args, **kwargs)
    298         num = len(clone)
    299         if num == 1:

/usr/lib/python2.5/site-packages/django/db/models/query.py in filter(self, *args, **kwargs)
    481         set.
    482         """
--> 483         return self._filter_or_exclude(False, *args, **kwargs)
    484 
    485     def exclude(self, *args, **kwargs):

/home/ghoseb/src/git/ocricket.git/ocricket/user/models.py in _filter_or_exclude(self, negate, *args, **kwargs)
     38             kwargs['username__iexact'] = kwargs['username']
     39             del kwargs['username']
---> 40         return super(MyQuerySet, self)._filter_or_exclude(negate, *args, **kwargs)
     41 
     42 class MyUserManager(UserManager):

/usr/lib/python2.5/site-packages/django/db/models/query.py in _filter_or_exclude(self, negate, *args, **kwargs)
    499             clone.query.add_q(~Q(*args, **kwargs))
    500         else:
--> 501             clone.query.add_q(Q(*args, **kwargs))
    502         return clone
    503 

/usr/lib/python2.5/django/db/models/sql/query.py in add_q(self, q_object, used_aliases)

/usr/lib/python2.5/django/db/models/sql/query.py in add_filter(self, filter_expr, connector, negate, trim, can_reuse, process_extras)

/usr/lib/python2.5/django/db/models/sql/query.py in get_meta(self)

<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute '_meta'

Mise à jour :. Soit dit en passant, je voulais simplement mentionner que lorsque je copie la logique dans ma méthode _filter_or_exclude dans la classe QuerySet réelle, il fonctionne parfaitement

Answer 1

Les gestionnaires ne peuvent pas être ajoutées à des classes avec affectation d'attribut simple (User.objects = MyManager()). Regardez la métaclasse ModelBase (db / modèles / base.py) pour voir ce que tout est fait pour vous dans les coulisses lorsque vous sous-classe modèle.

Vous devriez être en mesure de le faire fonctionner avec User.add_to_class('objects', MyManager()). Sinon, vous pouvez faire une sous-classe proxy de utilisateur et ajouter le gestionnaire il.

Answer 2

Vous ne voulez pas gâcher avec des fonctionnalités internes des classes de Django. De cette façon, est la difficulté à chaque mise à jour à l'avenir.

Si vous voulez changer la façon authentifient, écrire un backend d'authentification personnalisée.

Voici deux recettes.

http: // www. davidcramer.net/code/224/logging-in-with-email-addresses-in-django.html

http://www.djangosnippets.org/snippets/577/

Ces deux nous par courriel au lieu de nom d'utilisateur. Il n'est pas difficile d'utiliser la requête insensible à la casse au lieu d'une requête e-mail.

Answer 3

Voici une recette pour l'utilisation auth cas: Django: Cas correspondant insensible du nom d'utilisateur de l'utilisateur auth Vous êtes probablement mieux loti en utilisant des solutions distinctes pour chacun de vos cas d'utilisation.