L'autre option est que si vous avez un filtre que vous voulez toujours appliquée, d'ajouter un custom manager sur le modèle en question qui applique toujours le filtre aux résultats retournés.
Un bon exemple est un modèle Event
, où 90% des requêtes que vous faites sur le modèle que vous allez vouloir quelque chose comme Event.objects.filter(date__gte=now)
, à savoir que vous êtes normalement intéressé par Events
qui sont à venir. Cela ressemblerait à ceci:
class EventManager(models.Manager):
def get_query_set(self):
now = datetime.now()
return super(EventManager,self).get_query_set().filter(date__gte=now)
Et dans le modèle:
class Event(models.Model):
...
objects = EventManager()
Mais encore une fois, cela vaut le même filtre contre toutes les requêtes par défaut effectuées sur le modèle Event
et est donc pas aussi souple certaines des les techniques décrites ci-dessus.
Merci pour la clarification du concept de design de django. J'utilise l'approche de la méthode du modèle. – Ber
Bonjour les gens est 2014 maintenant! Environ 6 ans plus tard, les bibliothèques JS ont fait d'énormes progrès, et le filtrage d'une quantité de données pas extrêmement importante devrait plutôt être fait du côté client avec le support d'une belle bibliothèque de scripts java, ou au moins AJAX-ed. – andi
@andi: Je suis certainement d'accord pour des ensembles de données, même modérément grands, par exemple. même des milliers de lignes dans une table. Ayant travaillé sur des bases de données avec des millions de lignes, il y a toujours une place pour le filtrage côté serveur :) –