jeantil / admission_post_bac Goto Github PK

J'ai fait un rapide modèle des tables et des relations. Sans cardinalité, difficile d'y voir plus clair. En plus, les "jointures" dans le where ne rendent pas la tâche de relecture plus facile. Evidemment, aucune norme n'est respectée (doublons des noms des champs dans la base, pas d'alias, etc.)

Une certaine structure se détache, si j'en crois une certaine logique du code :

• les champs avec le même préfixe que la table à laquelles ils appartiennent sont des attributs de la table ;
• les champs communs entre deux tables sont les clés étrangères > clés primaires (donc relation 0,n - 1,1)
• il faut réussir à relieer les relations 0,n-0,n là c'est pas gagné...

Ne peut-on pas se dispatcher les requêtes pour aller plus vite? Comment voulez-vous faire le retro-enginering sur la structure? en sql direct?

Je propose de réaliser une explication détaillé du code, morceau par morceau, afin de pointer clairement ce qui pose problème et ce qui manque. Le nommage pourrait être "apb_ll4-20.sql" pour les paramètres de la fonction gen_class_alea_V1_relatif_grp, etc. Dans le fichier :

1. une reproduction du code
2. une mise en forme si nécessaire (pour arriver à un PL/SQL plus intuitif (par ex. les deux CURSOR ... IS seraient plus clairs avec un LEFT JOIN et sans UNION)
3. Une explication détaillée du fonctionnement du bout de code.

Le document explicatif (https://github.com/arnaudriegert/comprendre-apb/blob/master/apb/static/algorithme-apb-menesr.pdf) précise que

Ce classement donne priorité aux candidats de l’académie du siège de l’établissement proposant la formation non sélective dont les capacités d’accueil sont insuffisantes pour retenir l’ensemble des candidatures puis puis tient compte des tient compte des préférences exprimées par le candidat.

Est qu'il est possible de dire précisément où cette priorité est mise en oeuvre dans le script abp.sql (ou bien si elle est mise en oeuvre avant l'appel ou simplement dans le paramétrage de l'appel) ?

(Cf. question dans le message initial de @GuillaumeTara dans #17)

Hello,

On a reçu ces docs qui correspondraient à des schémas de certaines tables de la base de données. Je n'ai pas encore eu le temps de tout dépioter, du coup je ne sais pas si ça correspond à notre cas de figure, mais j'imagine que ça peut quand même :

https://drive.google.com/drive/folders/0B6a96AZlutX9RjRZLWxySjYxUVU

D'apres le fichier des variables, g_ti_cod correspondrait a code confidentiel inscription.

On pourrait l'extrapole au parametre en entree o_g_ti_cod.
Hors, a la lecture du code, ce parametre ne semble pas etre utilise comme un code confidentiel. Il est souvent utilise comme une cle de jointure.

Et puis il y'a ca lignes 290-292 :

      ||'Erreur traitement d''un candidat AC pour l''étab'
      || o_g_ea_cod_ins ||' et la formation '|| o_g_ti_cod||':'|| o_c_gp_cod ||', le candidat'||c_rec.g_cn_cod
      ||' et le groupe : '||o_c_gp_cod||', rg :'||i;

Donc (o_)g_ti_cod correspondrait plus a un code formation.

Au départ, on suppose qu'on possède, par candidat, une liste ordonnée de voeux de formation (table a_voe).

A la sortie de la fonction gen_class_alea_V1_relatif_grp, on a, par formation, une liste ordonnée (supposons que ce soit fait correctement) de candidats.

Il me semble qu'il nous manque la partie qui réalise le couplage entre candidat et formation.

Dans ce domaine, il y a le classique algorithme de Gale-Shapley pour déterminer les mariages stables (cet algorithme, correctement implanté, garantit qu'on n'aura pas deux couples de candidats-formations tels que C1 est associé à F1, C2 associé à F2, mais C2 préfère F1 et C1 préfère F2). Mais il existe certainement d'autres possibilités de couplage biparti à partir de listes de préférences.

Quoi qu'il en soit, la question de la manière dont est réalisé le couplage a, je pense, autant d'importance que la règle de classement : quel est l'algorithme utilisé ? cet algorithme est-il correctement implanté ?

Comme cette question n'a pour l'instant pas été soulevée ici, est-ce qu'il y a erreur de ma part ou est-ce que ça fait partie des choses à demander pour la prochaine "livraison" ?

https://gist.github.com/Benoitlecorre/30b76f7fda430d4a06063a7cfc5e3844 is more up-to-date (although it has typos)

Tel quel, ce code ne compile tout simplement pas. Il est plein de fautes basiques, je vais faire une petite liste rapide.

Ligne 164 :
THEN mess_aff:='On ne peut forcer un classement sur la base d''exploitation.',
Cette ligne devrait finir par un point-virgule.

Ligne 206 :
mess_aff='Un classement a déjà été saisi pour le groupe de cette formation :'
Mauvais signe pour l'affectation de valeur (:= et non =).

Ligne 231 :
|| o_c_gp Cod;
Il manque probablement un underscore. la variable devrait en réalité s'appeler o_c_gp_cod.

Ligne 242 :
ELSE mess_aff='On ne peut traiter ce type de classement aléatoire dans ces conditions :
Mauvais signe pour l'affectation de valeur (:= et non =).

Vraiment étrange de fournir du code non fonctionnel.

tout est dans le titre: vous auriez des exemples de jeux de données?

Bonjour,

Le lien vers rue89 dans le ReadMe est mort http://rue89.nouvelobs.com/2016/10/18/voici-code-source-dapb-tenu-secret-jusqua-present-265443

Il semble qu'ils aient changé de nom de domaine vers http://tempsreel.nouvelobs.com/rue89
Je n'arrive pas a retrouver le lien vers l'article.

Lucas

Hello,
Le lien https://droitsdeslyceens.com/medias/files/algorithme.pdf est mort.
J'ai téléchargé le document sur archive.org en PJ de l'issue, pour éventuellement le mettre directement sur le repo :-)
algorithme.pdf

https://github.com/emersion/apb

We should invite him to merge.

Hello,

Je viens vers vous avec une question qui est assez cruciale dans l'algorithme...

Ligne 102 on a un DECODE(l_six_voe, 1, six_voeu_L1(c.g_cn_cod, g_aa_cod_bac_int, g_cn_flg_int_aca, o_g_tg_cod), 0) qui est le deuxième attribut du select.

En gros, on nous génère un booléen. Derrière, dans le order by il y a "ORDER BY 2 desc" (ligne 149). EN gros, ce booléen est discriminant puisqu'il va placer les candidats ayant un 1 dans tous les cas avant ceux qui ont un 0, quel que soit l'ordre de leur voeu.

Mais comment comprendre ce Decode ?

D'après la doc que j'ai pu lire, on va effectuer ces étapes :
IF l_six_voe == 1
THEN RETURN six_voeu_L1(c.g_cn_cod, g_aa_cod_bac_int, g_cn_flg_int_aca, o_g_tg_cod)
ELSE RETURN 0

Dans un premier temps, j'avais cru que ce booléen représentait le critère d'appartenance à l'académie du candidat. Car normalement la règle d'APB veut que les candidats de l'académie soient prioritaires.

Or, ici, en regardant le nom des variables et après une discussion avec une journaliste éduc à l'étudiant il semblerait plutôt qu'on soit en train de vérifier si les candidats ont bien rempli les 6 voeux. Car, en effet, en île de france les candidats doivent avoir rempli 6 voeux en licence.

Mais ce serait bizarre pour 2 raisons :
(i) Cette règle ne s'applique qu'aux candidats de l'ile de France
(ii) A quel moment dans le code vérifie-t-on le critère académique ? Parce qu'à aucun autre endroit dans les classements on ne semble checker si le candidat habite dans l'académie de la formation. Or, si c'est le cas il devrait être avantagé dans les classements.

Pour bien comprendre ce qui se passe, il nous manque le code de la fonction six_voeu_L1, j'en conviens.

Mais si on part du principe qu'on vérifie le critère des 6 licences, cela voudrait dire que le code fournit par APB ne correspond qu'aux licences d'IDF.... A moins que je ne sois passé à côté du critère géographique.

Qu'en pensez-vous ? Si vous avez des pistes d'éclairage, je suis preneur...

Voici un lien vers la version colorisée du code avec

• arguments de la fonction
• variables internes
• tables,
• commentaires perso

Moi, ça m'a permis de bien comprendre le code.

https://docs.google.com/document/d/1fZE7mh81Pb6MKJmw73BTKNxhunZT0QUn57GkX6g_7wQ/edit

Si je fais une pull request avec renommage global de toutes les variables ça vous intéresse ? J’utiliserai pour ça les noms qui sont dans le fichier variable.txt, en prenant soin de régler les litiges sur la nomenclature avec vous dans les réponses à cet incident !

Bonjour,
On trouve dans le code «RANDOM.values(1, 999999)» à plusieurs reprises. Je n'ai pas encore lu l'ensemble du code mais il semble que ça serve à départager les candidats. Pour cela, il faut éviter de tomber deux fois sur la même valeur (ce qu'on appelle une collision).

Or le paradoxe des anniversaires (le fait que dans une assemblée de 24 personnes, il y a au moins une chance sur deux que 2 personnes aient la même date d'anniversaire) dit essentiellement que la probabilité d'avoir une collision lors de k tirages indépendants parmi n valeurs équiprobables est importante lorsque k est de l'ordre de racine de n. Si on tire au sort entre 1000 candidats, on y est... (Peut-être que ça n'a pas d'impact par la suite, mais ça n'est pas très bon signe quand même.)

De manière plus générale, l'utilisation d'un tirage au sort ici me semble poser pas mal de questions :

1. Quel est le générateur utilisé ? Est-il vraiment solide ? La graine choisie est-elle de taille suffisamment grande pour qu'on puisse considérer qu'il y a effectivement un choix au hasard parmi à peu près toutes les situations possibles plutôt qu'un choix tordu mais arbitraire entre certaines d'entre elles ?
2. Comment garantit-on que celui qui lance l'algo ne le relance pas si le résultat ne lui convient pas ? Dans les tirages au sort un peu sérieux, on fait appel à un huissier. Ne conviendrait-il pas ici qu'un huissier tire une graine au hasard (avec un procédé physique) et l'introduise dans le système de façon à ce qu'on puisse par la suite faire un audit en cas de contestation.

Ce n'est pas comme si ces questions étaient totalement nouvelles : il existe des protocoles cryptographiques conçus pour pouvoir tirer des valeurs au hasard de façon à garantir que la fraude ne soit pas possible (dans certaines limites). Vu la sensibilité des données manipulées, APB ne devrait-il pas les utiliser ?

Judicaël Courant
(Enseignant d'informatique, c'est cependant en tant que citoyen que je m'exprime ici).

Je cite l'article du Monde :

Mais la communauté des développeurs mobilisés autour du document rendu public demande « le code source complet de l’application » afin de comprendre les interactions possibles du reste du code avec la partie rendue publique.

Impossible, répond une fois de plus le ministère, en invoquant « des raisons de sécurité ». La plateforme faisant chaque année l’objet d’attaques de pirates informatiques (restées inoffensives pour l’instant), « aucun risque » ne sera pris en dévoilant le code source, et donc de possibles failles de sécurité dans lesquelles pourraient s’engouffrer des pirates informatiques.

Est-ce que l'argument de la sécurité vous paraît crédible (en pensant également à la prochaine demande) :

• pour ne pas communiquer la structure de la base ?
• pour ne pas communiquer les données "fixes" (académies, formations, etc.) ?
• pour ne pas communiquer la totalité du batch PL/SQL ?
• pour ne pas communiquer le code la totalité de la partie métier de l'application ?

(Plusieurs choix possibles, ne pas hésiter à se référer aux classiques type "injection SQL" ou même "buffer overflow" !)

heu ligne 268 sa serais pas plutot "X: = 06" ??

Bonjour,

J'ai lu à plusieurs reprises l'idée que l'ordre des voeux serait négatif et que cela pourrait expliquer pourquoi on met 0 à un voeu qu'on ne veut pas.

Mais cette théorie me paraît étrange... Prenons un cas concret.
X a classé la formation T en voeu 1
Y a classé la formation T en voeu 3
Z n'a pas classé la formation T

L'algo donne donc la valeur 0 au classement de Z
On a donc X = 1, Y = 3, Z = 0.
En toute logique on voudrait
X
Y
Z
Mais les deux cas de figure ne retournent pas ce résultat.
Si on classe tel quel ça donnerait :
Z = 0
X = 1
Y = 3
Si les voeux sont stockés négativement => X = -1, Y = -3, Z = 0 donc l'odre donne :
Y = -3
X = -1
Z = 0

Du coup ça me paraît tout aussi bizarre.... Ou peut-être que je pase à côté de quelque chose dans cette idée d'ordre de voeux négatif... Si ça se trouve les voeux sont positifs et autre part dans le code qu'on n'a pas, il y a une fonction qui élimine tous les voeux 0 ?...
Ou alors comme dans tous les cas ils n'ont pas classé le voeu, il ne le leur sera pas proposé et donc d'une manière ou d'une autre ils seront éliminés de la liste ce qui explique qu'ils soient laissés dans la liste à cette étape...

Bonjour à tous,

Ayant moi même eu à faire face à l'instabilité de ce code il y a deux ans je propose de conteneuriser cette application pour éviter toute implosion de la machine de test.

Je recommande la technologie de pointe Marcel Docker pour faire face à ce genre d'insectes.

Merci d'avance.

mais non indentée dispo à http://pastebin.com/hfWKUmUU

Déjà, ça commence bien, la requête qui va de la ligne 48 à la ligne à la ligne 96 me gène un peu, elle semble contraire aux commentaires écrits dans le fichier. Son résultat est stocké dans le pointeur de parcours classement_aleatoire_efe

Elle prend tous les candidats de type bac EFE qui ont "fait des voeux",
elle joint ce résultat à la liste des candidats de bac EFE qui n'ont pas fait de voeux (le mot clé UNION) en dédoublonnant les résultats (si un dev de base Oracle pouvait me confirmer que UNION et UNION ALL se comportent bien de cette façon avec Oracle)

Première remarque : ça semble complètement stupide de dédoublonner les résultats, car d'un coté nous avons les utilisateurs qui ont fait un voeu : la jointure dans le where (tssss) sur la table a_voe et dans l'autre partie du UNION, nous avons l'espèce d'horreur ligne 95 :
AND NOT EXISTS (SELECT 1 FROM a_voe v WHERE c.g_cn_cod=v.g_cn_cod AND r.g_ta_cod=v.g_ta_cod)

Donc à priori, il ne peut pas y avoir de doublons. Mais bref.

Plus gênant, le commentaire indique :

les candidats EFE qui n'ont au final pas classé la formation dans leur liste ordonnée. Ils sont classé, mais en dernier.

Hors, si je ne m'abuse
Premier SELECT va retourner le résultat suivant (exemple) :
Identifiant du candidat | Ordre du voeu avec voeux groupés relatifs licence | Ordre du voeu avec voeux | groupé relatif licence et tous les autres voeux | Ordre du sous-voeu dans le voeu groupé | Valeur aléatoire pour gérer les égalités | i.i_ep_cod

avec pour valeur
XYZ | 2 | 3 | 5 | 65745 | 1

UNION

Le deuxième SELECT qui va retourner le même nombre de colonnes, mais avec "en dur" les voeux à 0
ABC | 0 | 0 | 0 | 41674 | 1

Résultat avant le tri :
XYZ | 2 | 3 | 5 | 65745 | 1
ABC | 0 | 0 | 0 | 41674 | 1

Maintenant, observons le ORDER BY 2, 3, 4, 5; ( qui indique qu'il faut trier les colonnes 2 par ordre croissant, 3 par ordre croissant , etc.)

Résultat après le tri :
ABC | 0 | 0 | 0 | 41674 | 1
XYZ | 2 | 3 | 5 | 65745 | 1

Le candidat sans voeux arrive avant le candidat qui a fait des voeux

Donc il me semble que clairement, les candidats qui n'ont pas fait de voeux sont classés avant. Notez que ça d'ailleurs été corrigé dans la requête suivante, ligne 149, la présence d'un tri décroissant.

Qu'en pensez vous ?

Sur ce point, la page du wiki est très générale et un peu irréaliste Je pense qu'il faut être plus précis.
En vrac, quelques questions et remarques :

• Je vois mal l'EN donner le front-end de son site APB, et ça n'aurait pas de sens.
• Le caractère fake du jeu de données doit-il concerner seulement les candidats, ou également les formations, etc ? Il y a des paramètres importants qu'il serait intéressant de pouvoir contrôler.
• Il manque la demande du code... manquant.
• Il manque la demande du cahier du cahier des charges, des tests, des docs, etc.
• Pour la base, il faut également savoir comment elle est alimentée (pas seulement par les candidats).
• Utilisateurs de la base et autorisations.

Bon, ça fait beaucoup, mais autant voir large dans un premier temps, quitte à réduire. Quelles sont vos idées ?

Je pense qu'il faudrait penser à mettre un peu d'ordre dans ce repo : tout est placé dans src, alors que la plupart des fichiers n'ont pas vocation à être des sources. Je propose donc une réorganisation comme suit :

src/apb-original.sql <- le plus proche possible du PDF
src/database.sql <- la structure de la base sous format minimal
doc/detail-code/01-declaration_apb_004-044.sql
doc/detail-code/...
doc/detail-code/15-X14-detail-code_apb_387-404.sql
doc/dictionnaire-script.md
doc/variables.txt
doc/documents/Table voeux.pdf <- tous les documents utilisés
doc/documents/...