01:56 <alain_afpy> Sortie de Django 5.2 - https://www.djangoproject.com/weblog/2025/apr/02/django-52-released
08:48 <discord_afpy> <saturn7694> ah ah j'avais jamais remarqué que Django n'avait pas de composite PK
08:58 <discord_afpy> <agnes1825> J'ai remarqué pas plus tard que ce lundi 🤗 coïncidence amusante
09:11 <discord_afpy> <saturn7694> c'est vrai que c'est un truc bien utile mais dont on a pas toujours besoin
09:12 <discord_afpy> <saturn7694> donc c'est normal de pas s'en rendre compte tout de suite
10:01 <discord_afpy> <Dorian TURBA> composite pk, c'est quand on a une clé primaire composé de deux colonnes c'est ça ?
10:02 <discord_afpy> <Dorian TURBA> (deux ou plus, vous m'avez compris)
10:03 <discord_afpy> <Dorian TURBA> je suppose que c'est ce qu'ils entendent par "multiple fields"
10:13 <discord_afpy> <saturn7694> oui c'est ça
10:14 <discord_afpy> <saturn7694> on peut trouver des "workaround" si ç'est pas possible donc je comprends que ça arrive si tard
10:32 <discord_afpy> <chadys> c'est surtout considéré comme une mauvaise pratique, néanmoins pour les systèmes legacy sur lesquels ont a pas la main ben... ça sert malheureusement et c'était très demandé à cause de ça
10:48 <discord_afpy> <saturn7694> bon il y a plein de mauvaise pratique largement répandues en SQL
10:49 <discord_afpy> <saturn7694> https://stackoverflow.com/questions/26078535/composite-primary-keys-good-or-bad
10:52 <discord_afpy> <saturn7694> pour faire une relation M2M qui porte des données c'est quand même le plus logique je pense
10:53 <discord_afpy> <saturn7694> en tout cas le plus facile
10:54 <discord_afpy> <saturn7694> Tu peux avoir un Model avec deux FK mais parfois ç'est compliqué de leur trouvé un nom, quand tu est censé justemetn modéliser une relation
10:57 <discord_afpy> <saturn7694> Et franchement faut vraiment aimé Django pour vouloir l'utiliser sur une BDD legacy. SQL alchemy est beaucoup plus adapté pour ça
11:02 <discord_afpy> <eyecontrol> On ne peut pas utiliser SQLAlchemy avec Django ?
11:02 <discord_afpy> <eyecontrol> On m'avait dit qu'on pouvait choisir son ORM (même si a priori Django ORm est généralement utilisé)
11:16 <discord_afpy> <Dorian TURBA> Il me semble que si mais c'est comme vouloir faire une pizza dans un four à gateau ("ça existe pas un four à gateau" gneugneugneu tu vois ce que je veux dire)
11:16 <discord_afpy> <Dorian TURBA> J'ai un projet dans un carton pour faire du SA dans Django, mais j'ai jamais eu la motive de le faire
11:16 <discord_afpy> <Dorian TURBA> Si jamais tu es super motivé, on pourra regarder ensemble si tu veux
11:17 <discord_afpy> <Dorian TURBA> Hahaha
11:19 <discord_afpy> <chadys> C'est pas trop fait pour non, après tout est toujours possible
11:19 <discord_afpy> <Dorian TURBA> Challenge accepted
11:20 <discord_afpy> <Dorian TURBA> @Karine a cause de toi, je finirais jamais ce mud, tu casse les pieds avec tes idées à la noix
11:20 <discord_afpy> <chadys> tout dépend de ce que tu veux en faire, j'ai utilisé django avec une DB2 AS400 de la mort pour quelques tables et comme c'était du django partout ailleurs et que l'équipe était à l'aise avec, ça faisait sens
11:22 <discord_afpy> <chadys> Je comprends pas la problématique, c'est le nommage de la table "through" du manytomany ? Et puis même dans ce cas avec tes deux foreignkey, rajouter une pk explicite évite l'utilisation des clefs composites
11:23 <discord_afpy> <saturn7694> ça a longtemps été impossible en tout cas
11:23 <discord_afpy> <chadys> je vois pas en quoi ce serait plus facile avec clef composite, tu économise un champ, mais à quel prix
11:24 <discord_afpy> <saturn7694> après c'est une question de goût, d'équipe etc... mais connaissant les deux sur ce cas précis j'aurais tendance à privilégier SA
11:25 <discord_afpy> <saturn7694> c'est plus lisible en terme de modèle métier. Faudrait surtout dire ce qu'est ce fameux pris à payer
11:27 <discord_afpy> <Dorian TURBA> si tu as une table avec des champs dont aucun n'est unique, mais la combinaison l'est, et que tu as d'autres tables avec ces données, plutôt que de devoir faire une traduction des info composite pour récup l'id et utiliser l'ID partout, l'usage de la clé composite t'évite de le faire
11:27 <discord_afpy> <Dorian TURBA> +1 pour Mik: quel prix ?
11:29 <discord_afpy> <Dorian TURBA> je suis loin d'être bon en SQL, mais tu me donne des lignes avec A, B (qui pourrait être la clé composite) à inserer en DB, si AB ne sont pas CPK et que je dois récup l'ID avant de pouvoir inserer les données, je ne sais pas comment faire sans une requete intermédiaire super lourde pour préserver l'ordre de requete et récuperer tout les ID.
11:30 <discord_afpy> <Dorian TURBA> du genre, en proto code, select user.id where user.a + user.b in [list of composite AB]
11:31 <discord_afpy> <saturn7694> Pour moi Django ça a toujours été un framework pour modéliser rapidement et de manière acceptable un métier sur une table ad hoc. et SA plus un framework pour faire des trucs avec une base de données (legacy, ou pas). On peut interchanger les rôles mais il y a clairement des domaine ou l'un brille plus que l'autre et inversement
11:31 <discord_afpy> <Dorian TURBA> c'est quoi une table adhoc?
11:31 <discord_afpy> <chadys> pourquoi c'est plus lisible? Tu as quand même tes deux foreignkey qui pointent ou il faut.
11:31 <discord_afpy> <chadys> prix à payer par exemple :
11:31 <discord_afpy> <chadys> - api http plus complexes pour manipuler les objets
11:31 <discord_afpy> <chadys> - convention django avec le suffixe "_id" qui permet d'accéder aux PK étrangère sans se poser de question ni avoir besoin de connaitre le détail du schema.
11:31 <discord_afpy> <chadys> - les colonnes utilisés en clefs composite il faudra faire attention de ne jamais les modifier, donc il doit s'agir de colonne sans sens sémantique
11:32 <discord_afpy> <saturn7694> un base pardon. une base from scratch (ad hoc ça veut dire fait pour répondre au besoin)
11:32 <discord_afpy> <Dorian TURBA> > api http plus complexes pour manipuler les objets
11:32 <discord_afpy> <Dorian TURBA> Pour moi, qu'une PK soit Nom Prénom me semble plus facile pour lire et manipuler qu'un ID abstrait qui ne serait qu'une surcouche, nécessitant un get id (nom prénom)
11:33 <discord_afpy> <chadys> Un where avec des index là ou il faut et tu ne te sert de l'ID que là ou tu en a besoin, pas pour une création de relation
11:33 <discord_afpy> <captainkro> Ou là là.
11:33 <discord_afpy> <Dorian TURBA> > sans se poser de question
11:33 <discord_afpy> <Dorian TURBA> Pour moi, c'est plutôt ça un anti-pattern
11:34 <discord_afpy> <chadys> ben non, si tu utilise des pk unique partout, tu sais que tu récupère une pk, c'est quand même sacrément moins complexe que de devoir regarder à chaque fois
11:34 <discord_afpy> <Dorian TURBA> mais je vois pas en quoi une clé composite t'empeche de savoir que tes champs sont des foreign key composite (si ça existe), _id pourrait récuperer ces champs aussi, pourquoi pas (si ça se trouve, ça fait parti de l'update dont on parle)
11:35 <discord_afpy> <Dorian TURBA> mais si j'ai une table avec une CPK, faire _id devrait me retourner les champs de la CPK
11:35 <discord_afpy> <chadys> surtout pas de sens sémantique dans quelques chose qui est utilisé en clef... une clef ne doit pas changer sinon il faut mettre à jour partout ou elle est référencé.
11:35 <discord_afpy> <Dorian TURBA> sinon, c'est juste un feature relou qui bride les features utilisables...
11:35 <discord_afpy> <chadys> c'est justement à cause de ce genre de tentation que les clefs composites sont mal vue
11:36 <discord_afpy> <saturn7694> bon pour vous mettre un peu d'accord aujourd'hui j'ai tendance a faire une classe pour ça. Mais d'un autre côté avec les bonnes abstractions (SA les a) c'est assez gérable
11:37 <discord_afpy> <Dorian TURBA> "les colonnes utilisés en clefs composite il faudra faire attention de ne jamais les modifier, donc il doit s'agir de colonne sans sens sémantique"
11:37 <discord_afpy> <Dorian TURBA> C'est le principe d'une PK, c'est le même probleme pour une table pk id, si tu fais une CPK, ça tombe sous le sens.
11:37 <discord_afpy> <Dorian TURBA> J'ignore si SQL t'autorise à update un CPK si il est utilisé ailleurs d'ailleurs
11:37 <discord_afpy> <chadys> oui mais du coup tu est obligé de vérifier le type de ta pk avant de pouvoir l'utiliser ailleurs (par exemple, l'envoyer dans une API web
11:37 <discord_afpy> <chadys> ça rajoute de la complexité
11:37 <discord_afpy> <saturn7694> > J'ignore si SQL t'autorise à update un CPK si il est utilisé ailleurs d'ailleurs
11:37 <discord_afpy> <saturn7694> non bien sûr que non
11:38 <discord_afpy> <Dorian TURBA> > surtout pas de sens sémantique dans quelques chose qui est utilisé en clef... une clef ne doit pas changer sinon il faut mettre à jour partout ou elle est référencé.
11:38 <discord_afpy> <Dorian TURBA> Mais il y a plein de cas métier où ça ne change pas, ou que si il y a un changement, il est assez rare pour se permettre un update partout, genre Nom Prénom Date de naissance
11:38 <discord_afpy> <saturn7694> des fois la sémantique c'est un tuple
11:38 <discord_afpy> <Dorian TURBA> > non bien sûr que non
11:38 <discord_afpy> <Dorian TURBA> Bon bah c'est un faux probleme du coup non ?
11:38 <discord_afpy> <chadys> et donc tu as besoin de 2 colonne qui remplissent ce contrat
11:38 <discord_afpy> <saturn7694> on peut encapsuler ça dans une classe mais ça reste une relation
11:39 <discord_afpy> <Dorian TURBA> oui, c'est le principe, on signe pour ça avec une CPK, je vois pas où tu veux en venir
11:39 <discord_afpy> <saturn7694> dans la table qui référence oui
11:40 <discord_afpy> <saturn7694> d'un autre côté tu peux référencer la pk unique et avoir le couple de l'id composite qui change
11:40 <discord_afpy> <saturn7694> ça peut être un problème
11:40 <discord_afpy> <chadys> je veux en venir que, autant dans le cas d'un manytomany effectivement tu rempli se contrat facilement, en utilisant les pk simple des tables référencé, autant pour toutes les autres tables, ce n'est pas le cas, donc tu vas créé une colonne dédié, donc PK simple dans tous les cas
11:40 <discord_afpy> <Dorian TURBA> @Chadys si tu reçois de la donnée qui a ces deux champs (ou x) (sans, pas de lien possible, la clé n'est pas entière) mais pas l'ID PK que tu as décidé de faire à la place, tu ferais quoi toi ?
11:40 <discord_afpy> <captainkro> J'ai travaillé des années avec une énorme bdd qui avait des clés composites partout (en suivant une logique métier) sur un très gros logiciel de scolarité utilisé par une grande partie des universités. C'est tellement été l'enfer pour tout le monde (éditeur comme exploitant) que le nouveau remplacant a bani les pk composites.
11:40 <discord_afpy> <captainkro>
11:41 <discord_afpy> <chadys> ben ça dépend ce que j'ai besoin de faire, mais naivement je dirait, un select ou un udapte avec une clause where? ça change rien en faite
11:42 <discord_afpy> <Dorian TURBA> mais en quoi avoir deux champs au lieu d'un est un probleme ? C'est pour économisé une colonne qu'on parle du oui/non CPK ?
11:42 <discord_afpy> <saturn7694> oui c'est la souci, mais on s'en crée d'autres en faisant ça (voir mon message précédent)
11:43 <discord_afpy> <chadys> tu as des contraintes qui te protèges pour évité que ce soit un problème
11:43 <discord_afpy> <saturn7694> moi ma conlusion après c'est année c'est que une table relationnel ne garantie jamais la cohérence
11:43 <discord_afpy> <Dorian TURBA> donc si j'ai 10 000 insert à faire de lignes avec ABC, AB pouvant être CPK, toi tu fais quoi ? un select ? En plus ? Avec un Where in ou du genre ? Tu peux être plus explicite, c'est hyper flou pour moi là
11:43 <discord_afpy> <chadys> "ça ne change pas" -> s'avère toujours faux. Et la mise à jour est toujours un problème
11:43 <alain_afpy> scrollbar-canvas - https://discuss.afpy.org/t/scrollbar-canvas/2553
11:44 <discord_afpy> <Dorian TURBA> > J'ai travaillé des années avec une énorme bdd qui avait des clés composites partout (en suivant une logique métier) sur un très gros logiciel de scolarité utilisé par une grande partie des universités. C'est tellement été l'enfer pour tout le monde (éditeur comme exploitant) que le nouveau remplacant a bani les pk composites.
11:44 <discord_afpy> <Dorian TURBA> corélation n'est pas causalité
11:44 <discord_afpy> <saturn7694> dans les deux cas tu peux ajouter des contraintes
11:44 <discord_afpy> <captainkro> Il faut que je retrouve le papier universitaire traitant du cas d'un erp qui avait été utilisé par peugeot il y a très long temps et qui utilisait les marques des boites et les noms des voitures comme pk. Une fusion plus tard et ça a couté des millions pour mettre à jour le systeme et pas mal de bug en prod
11:44 <alain_afpy> WARNING !!! YAKAFOKON DETECTED !!!!
11:45 <discord_afpy> <Dorian TURBA> @CaptainKro le probleme est exactement le même avec une PK mono champs
11:45 <discord_afpy> <saturn7694> oui mais est ce que le souci c'est les clefs composite ou le fait que les clef soit des noms de voiture
11:45 <discord_afpy> <saturn7694> ?
11:46 <discord_afpy> <Dorian TURBA> @CaptainKro Qu'est ce qui te dis que ta PK ne va jamais changer ? Genre, SSN utilisé en PK
11:46 <discord_afpy> <chadys> en gros, tu as une manytomany user+music, tu veux en ajouter plein et tu as dans ta table manytomany deux FK + une PK. ben tu fait ton insert avec ta liste de couple de FK, et la PK va se remplire toutes seule en utilisant, en général, une séquence. Donc pas de requête supplémentatire
11:46 <discord_afpy> <Dorian TURBA> mais là tu pars du principe que tu connais la PK interne de la DB
11:46 <discord_afpy> <chadys> il ne faut pas utilisé une SSN en pk, il faut un pk sans sens sémantique, c'est toujours la base que ce soit pour les pk simple ou composite
11:47 <discord_afpy> <Dorian TURBA> si c'est pas le cas (et c'est souvent pas le cas)
11:47 <discord_afpy> <Dorian TURBA> tu doit faire ces requetes supp
11:47 <discord_afpy> <Dorian TURBA> bah il est peut être là le probleme
11:47 <discord_afpy> <chadys> ben non ? Pourquoi j'en aurait besoin? je comprend pas ton scénario
11:47 <discord_afpy> <saturn7694> oui le vrais souci c'est ça en fait
11:48 <discord_afpy> <saturn7694> voir le message de @CaptainKro aussi
11:49 <discord_afpy> <saturn7694> il faut voir les pk et fk comme des identifiant technique et pas leur faire porter de sémantique métier
11:49 <discord_afpy> <saturn7694> et c'est un peu le souci avec les composites donc je comprends la position de @Chadys
11:49 <discord_afpy> <chadys> oui voilà!
11:50 <discord_afpy> <Dorian TURBA> Tu reçois des lignes à inserer, par exemple : A, B, Nom d'un traitement
11:50 <discord_afpy> <Dorian TURBA> A et B sont les info de l'utilisateur par exemple SSN + Nom
11:50 <discord_afpy> <Dorian TURBA> Tu n'a pas l'ID interne.
11:50 <discord_afpy> <Dorian TURBA> Pour inserer ABTraitement, tu fais comment ?
11:51 <discord_afpy> <saturn7694> Tu as une table ABTraitement et un Modèle surtout