Spring is hate...

Queryset-refactor

Toute la communauté Django est en émoi : la branche "queryset-refactor" a été fusionnée dans le tronc de Django (svn).

Cette branche porte en elle de profonds changements et améliore immensément le coeur de Django et le fonctionnement des requêtes sur les bases de données. L'une des améliorations fondamentales, de mon point de vue, c'est l'héritage des modèles. Le fondement même de la programmation orientée objet ne pouvait jusque là être transplanté dans ce framework. Par exemple, pour avoir un "profil utilisateur", jusqu'à présent, il fallait jouer du tournevis et avoir une structure à peu près comme suit :

from django.db import models
from django.contrib.auth.models import User

class MonProfilUtilisateur(models.Model):
    # pour lier l'utilisateur et son profil
    user = models.ForeignKey(User, unique=True)

    # Les autres infos...
    telephone = models.CharField(max_length=20)
    fax = models.CharField(max_length=20)

Soit une relation 1 - 1 avec le modèle "User". Bof bof... Et pour utiliser la notion de profil, il fallait rajouter dans settings.py :

AUTH_PROFILE_MODULE = "myapp.monprofilutilisateur"

Mouais.

Désormais, on pourra faire hériter un modèle par un autre et écrire :

class MonProfilUtilisateur(User):
    # Les autres infos...
    telephone = models.CharField(max_length=20)
    fax = models.CharField(max_length=20)

Ce qui est vrai pour les modèles "User" sera également vrai pour les modèles définis par le développeur, comme l'indique la documentation. Je pense que cette possibilité présente une avancée majeure dans Django, et elle ouvre des perspectives absolument détonantes.

Plus je réfléchis à l'héritage des modèles, plus j'entrevois de fonctionnalités qui en découleraient ; j'ai vraiment hâte de pouvoir tester tout ça.

Note : Pour le moment, l'héritage n'est pas intégré dans le module d'administration ; ce sera peut-être chose faite après fusion de la branche "newforms-admin" qui attend son heure, bien au chaud, depuis longtemps à présent.

28 Avril 2008 - 07:30, par NiKo

Hola, attention. L'héritage qui rajoute des champs à l'objet surchargé (heu, oui, l'héritage quoi) n'est pas forcémment la panacée en termes de perfs, puisque par exemple ton objet utilisateur va posséder un nombre de champs plus important, et donc une requête rappatriant plusieurs instances d'objets utilisateur va être de plus en plus lourde... Alors qu'en scindant utilisateur et profil tu te laisses le choix de charger les données du profil uniquement au besoin (et puis priviliégier la composition à l'héritage, ça reste une bonne pratique de maintenabilité de toute façon)... Bon au moins là ce qui est bien c'est que les gens ont le choix de faire comme ils veulent.

28 Avril 2008 - 09:03, par No'

Niko: Certes. Mais si ces informations sont "à stocker", c'est surtout parce qu'on en a besoin. Donc, qu'elles soient disponibles dans les requêtes ne me dérange pas trop.

Ce qui m'arrange aussi et surtout, c'est l'héritage des méthodes... Et là, bénéficier des méthodes du parent dans la ou les classes enfant, ça ouvre également moult perspectives...

28 Avril 2008 - 21:53, par vincent

L'avantage (pas dans le cas de ton exemple mais bon) c'est aussi le petit booléen abstract dans la sous-class Meta. Puisque là, c'est quasiment le même fonctionnement qu'une classe abstraite en java (d'où le petit nom du booléen certe :)).

C'est une très bonne nouvelle ce Queryset-refactor intégré au trunk de Django.

28 Avril 2008 - 21:54, par NiKo

> "Certes. Mais si ces informations sont "à stocker", c'est surtout parce qu'on en a besoin."

Ben le problème avec un ORM, c'est que t'en aies besoin ou pas c'est généralement à grand coup de SELECT 'étoile' que tu rapatries les enregistrements, ne serait-ce que pour garantir que tu as un objet complet à chaque fois (sinon on appelle ça un resultset, voire un tableau.)

Et donc si ta table users commence à stocker les 70 champs du profil, t'es pas couché quand tu fais un User.objects.all() ou équivalent... Donc méfiance, et c'est du vécu pusque j'ai fait la boulette sur Symfonians :P

Bref, si c'est pour ajouter deux colonnes, ça se défend sans doute. À voir au cas par cas. Mais j'aime bien l'idée de composition d'un modèle à une dépendance quand les deux sont strictement complémentaires.

> "Ce qui m'arrange aussi et surtout, c'est l'héritage des méthodes"

Ah ça oui y'a bon. Mais tu peux aussi créer des méthodes proxy vers ton objet profil... à la mano cependant.

28 Avril 2008 - 22:34, par NiCoS

moi je dis MiaM ! :)


Toutes les balises HTML seront supprimées.
Tu peux ajouter des liens comme suit :
J'ajoute [a http://exemple.com "un joli lien"]
Tu peux aussi mettre *en gras* ou {en italique}.