Produits Entr'ouvert » Authentic 2

Même question que pour #22251 : sur quoi se base-t-on pour déduire le slug ? Le nom de l'OU ?

Oui, slugify(ou.name).

(Et pour info, c'est documenté ici https://www.django-rest-framework.org/api-guide/fields/#default.)

Mais s'il y a deux appels, le second plante parce que le slug est le même ?

Du même avis que Fred, mais que le slug soit fourni ou calculer si les paramètre sont identiques, il faut juste renvoyer l'instance existante, je dirai qu'il faut faire un get_or_create() avec le slug seul, mettre à jour le nom si nécessaire et renvoyer l'instance trouvée. Ça ne peut pas se faire au niveau du serializer mais il faudrait plutôt surcharger ModelSerializer.create().

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

Mais s'il y a deux appels, le second plante parce que le slug est le même ?

S'il y a deux appels avec le même nom, on aura déjà un souci d'unicité, indépendamment du slug :

E           Bad response: 400 Bad Request (not 200 OK or 3xx redirect for http://testserver/api/ous/)
E           b'{"result":0,"errors":{"__all__":["The fields name must make a unique set.","The fields slug must make a unique set."]}}'

S'il y a deux appels avec le même nom, on aura déjà un souci d'unicité, indépendamment du slug :

Ok ajoute une modification du nom entre temps (ou utiliser deux noms différents qui donnent le même slug) et voilà tu as l'erreur dont je voulais parler. Ce que je veux dire c'est que via l'UI, où on n'entre pas de slug, on peut faire "créer A", "renommer A en B", "créer A", et le slug de ce second A est créé différent de celui de l'A initial. (a1 vs a)

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Du même avis que Fred, mais que le slug soit fourni ou calculer si les paramètre sont identiques, il faut juste renvoyer l'instance existante, je dirai qu'il faut faire un get_or_create() avec le slug seul, mettre à jour le nom si nécessaire et renvoyer l'instance trouvée. Ça ne peut pas se faire au niveau du serializer mais il faudrait plutôt surcharger ModelSerializer.create().

Je ne suis pas convaincu par le comportement get_or_create par défaut sur le POST. Pour moi si l'instance existe déjà il faut renvoyer un 40X, non ?
Dans l'API de rôles, par exemple, on n'a ces comportements “*_or_create” qu'en précisant des paramètres de querystring spécifiques.

Il y a la théorie et la pratique :) En théorie si on était des puristes, on devrait détecter l'erreur et la gérer dans le workflow qui appelle ça, en pratique les workflows sont beaucoup plus simple si aucune erreur n'est possible dans le fonctionnement normal (i.e. si les appels sont idempotents, en cas d'erreur technique temporaire on a juste à répéter les appels et ça fonctionne). Le cas d'un nom très différent donnant un slug identique sont impossibles. Dans les cas où on doit vraiment vérifier si l'objet existe déjà (et j'ai l'impression que pour les OUs ça n'arrivera pas) il n'y a qu'à faire un get avant.

Maintenant si tu veux vraiment avoir les deux comportements sur un même endpoint il faut réutiliser le GetOrCreateMixin utilisé sur l'API des utilisateurs (mais ça complexifie, à la fois les appels et les implémentations).

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

S'il y a deux appels avec le même nom, on aura déjà un souci d'unicité, indépendamment du slug :

Ok ajoute une modification du nom entre temps (ou utiliser deux noms différents qui donnent le même slug) et voilà tu as l'erreur dont je voulais parler. Ce que je veux dire c'est que via l'UI, où on n'entre pas de slug, on peut faire "créer A", "renommer A en B", "créer A", et le slug de ce second A est créé différent de celui de l'A initial. (a1 vs a)

Ce problème là plaide simplement pour exposer le champ slug (dans l'IHM), le slug est sensé être immuable mais pas de manière absolue, ce n'est pas un UUID, on doit pouvoir corriger un erreur temporaire de nommage à la main.

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

Ok ajoute une modification du nom entre temps (ou utiliser deux noms différents qui donnent le même slug) et voilà tu as l'erreur dont je voulais parler. Ce que je veux dire c'est que via l'UI, où on n'entre pas de slug, on peut faire "créer A", "renommer A en B", "créer A", et le slug de ce second A est créé différent de celui de l'A initial. (a1 vs a)

Ok oui je n'avais pas pensé à ce comportement, qu'on pourrait reproduire dans l'API.

Paul Marillonnet a écrit :

Je ne me rends pas compte de l'ajout de complexité (dans mes souvenirs le mixin dédié parvient bien à contenir la complexité de la chose). Je vais regarder ça.

Ça complexifie dans le sens où la personne qui fait l'appel doit penser qu'elle veut le comportement get-or-create et donc ajouter la clé ?get-or-create=slug dans la query-string et aussi qu'elle doit savoir que c'est sur le champ slug qu'il faut agir, ça fait beaucoup de détails techniques à transmettre via la documentation ou même simplement à apprendre aux CPFs.