Produits Entr'ouvert » Chrono

0002: dans la migration j'ai l'impression que « meeting_type.slug = slugify(meeting_type.label) » est inutile, parce que le meeting_type.save() fera tout le travail (et mieux, en plus).

À part ça, j'aurais aimé des "# legacy access from id" dans le code quand on cherche avec les id et non les slugs.

Je me demandais si on pourrait cette fois avoir un unique=True pour le slug d'Agenda, et un unique_together pour MeetingType ? En fait je mets ce commentaire en me demande si on a une raison de ne pas utiliser ces contraintes dans les modèles (on le fait rarement).

Discussion intéressante à avoir à un moment (HowDoWeDoDjangoModels…) (sans y avoir réfléchi assez, je pense que mon approche c'est que les contraintes au niveau de la db sont un dernier garde-fou, un peu comme un assert() dans du code, et qu'il doit donc de toute façon y avoir du code en amont qui s'assure que ces contraintes ne sont de toute façon pas violées).

Frédéric Péters a écrit :

Discussion intéressante à avoir à un moment (HowDoWeDoDjangoModels…) (sans y avoir réfléchi assez, je pense que mon approche c'est que les contraintes au niveau de la db sont un dernier garde-fou, un peu comme un assert() dans du code, et qu'il doit donc de toute façon y avoir du code en amont qui s'assure que ces contraintes ne sont de toute façon pas violées).

Je pense que ça ajoute automatiquement des validations sur les modelforms (sinon effectivement, c'est juste un garde fou)

Et donc : ack pour l'instant comme cela. On verra par ailleurs si on ajoute l'unicité dans le model.

Et j'ai mis à jour la page https://doc-publik.entrouvert.com/admin-fonctionnel/prises-de-rendez-vous/

Frédéric Péters a écrit :

Discussion intéressante à avoir à un moment (HowDoWeDoDjangoModels…) (sans y avoir réfléchi assez, je pense que mon approche c'est que les contraintes au niveau de la db sont un dernier garde-fou, un peu comme un assert() dans du code, et qu'il doit donc de toute façon y avoir du code en amont qui s'assure que ces contraintes ne sont de toute façon pas violées).

Ce n'est pas qu'un garde fou, c'est la seule garantie qu'un get_or_create() pourra être exécuté de manière atomique ou pas, en fait get_or_create() ne rend pas les services escomptés si les attributs (hors defaults) ne sont pas couverts par un index d'unicité, c'est pour ça qu'en général il faut toujours s'en servir comme ceci:

   instance, created = XXX.objects.get_or_create(indexed_attribute1=x, indexed_attribute2=y, defaults=defaults)
   if not created:
       for key in defaults:
           setattr(instance, key, defaults[key])
       instance.save()