UVa problems and submissions #1
Conversation
| }).then( | ||
| function(result) { | ||
| db.runSql( | ||
| 'CREATE TABLE submissions (\n' + |
There was a problem hiding this comment.
pq ne pas avoir utilisé db.createTable ? ce serait plus lisible et consistent.
There was a problem hiding this comment.
Parce que je ne pense pas qu'il supporte une primary key à plusieurs colonnes, en tout cas je n'ai pas trouvé.
There was a problem hiding this comment.
Si si, il faut juste le définir séparément la clé comme tu fais en SQL. Cfr http://sequel.jeremyevans.net/rdoc/files/doc/schema_modification_rdoc.html#label-primary_key
There was a problem hiding this comment.
Pas sûr qu'ils y aient pensé pour db-migrate: https://github.com/db-migrate/node-db-migrate/blob/master/lib/interface/migratorInterface.js.
There was a problem hiding this comment.
Ah oui, je ne sais pas pq je t'ai envoyé sur le migrateur de Sequel ruby ;-)
Mais si il le supporte vu que je l'ai fait dans la première migration, table scores
| var dbm; | ||
| var type; | ||
| var seed; | ||
|
|
There was a problem hiding this comment.
Est-ce que ça nous sert de stocker les détails des soumissions UVa? L'idée de base était d'uniformiser toutes les soumissions dans un format à nous et ainsi d'éviter de stocker des "détails inutiles" et de devoir faire des tables pour tous les formats supportés. Tout de façon il faut bien les interpréter à un moment, pourquoi ne pas les interpréter dès que possible et jeter l'info inutile ? Je ne dis pas que j'ai pensé à tout, c'est plutôt une réflexion...
There was a problem hiding this comment.
Je trouve le truc actuel plutôt minimaliste, surtout par rapport aux soumissions Codeforces (exemple: http://codeforces.com/api/user.status?handle=Fefer_Ivan&from=1&count=10). Les soumissions et les problèmes sont déjà uniformisés mais pour la table des utilisateurs UVa il n'y a pas le choix puisqu'il faut gérer la correspondance entre le username et l'id.
There was a problem hiding this comment.
Mais à un moment, tu devras bien "réduire" ça à qqchose de commun à notre plateforme. Stocker tout chez ne me semble pas nécessaire, mais tu veux essayer, vas-y.
| ).then( | ||
| function(result) { | ||
| db.runSql( | ||
| 'CREATE TABLE problems (\n' + |
There was a problem hiding this comment.
ce contenu était déjà prévu dans tasks
There was a problem hiding this comment.
Je pensais que tasks contiendrait les exercices assignés par les coaches. Et il n'y a pas de titres en français ni en néerlandais.
There was a problem hiding this comment.
Mmh oui le but est stocker tous les exercices qui ont de la valeur pour l'évaluation, donc pas tous les exercices mais bcp, triés par topic etc. Mais donc l'idée serait d'avoir des traductions fr/nl qui arrivent à un moment, mais pas nécessaire.
| exports.up = function(db) { | ||
|
|
||
| return db.createTable('uva_users', { | ||
| uva_user_id: { type: 'serial', primaryKey: true }, |
There was a problem hiding this comment.
Le premier attribut est un identifiant propre à nous ? Alors il faudrait plutôt utiliser comme clé la clé étrangère de users directement.
Si tu veux utiliser une table extérieure, il faut également virer les champs qui y étaient dédiés dans users.
There was a problem hiding this comment.
Pour moi, la table users contient les utilisateurs "privilégiés" pour lesquels on veut calculer les scores. Les différents services ont des besoins différents, et essayer de tout caser dans une seule table m'a l'air très foireux. Que doit-il se passer en cas de requête sans username Codeforces d'un utilisateur qui n'avait pas encore fait de requête, par exemple ? Il faut aller chercher les soumissions sur UVa et ensuite, il faut les stocker où ? Et on fait quoi des champs Codeforces ?
Je ne sais pas si cet attribut a une grande utilité, je vais regarder si je dois le virer.
There was a problem hiding this comment.
Cela dit, je n'ai pas encore viré les champs inutiles des autres tables. Et je n'ai pas encore rajouté les indexes.
There was a problem hiding this comment.
Je ne suis pas à 100% certains d'avoir compris ta question mais l'idée était de parser de temps en temps les updates UVa et Codeforces pour chaque utilisateur, d'insérer les avancements relevants pour nous (c'est-à-dire liés à une tâche définie dans topic_tasks ) dans activities. Et d'utiliser ça après pour faire la mise à jour continue des scores.
There was a problem hiding this comment.
Je pensais stocker les infos de tous les utilisateurs qui ont sollicité la plateforme, et d'utiliser ces infos pour les quelques utilisateurs privilégiés (à savoir ceux qui participent à beCP) afin de mettre à jour leurs scores à intervalles réguliers.
Je me dis que la plateforme peut servir comme uniformisation des services uHunt, Codeforces, ... et qu'elle peut en plus nous permettre de calculer les scores relatifs aux différents contestants belges.
Uniformiser les soumissions pourrait me permettre d'intégrer plus de plateformes sur la page d'accueil de mon site sans difficultés (http://beoi-training.herokuapp.com/) et ainsi d'avoir plus de visibilité sur ce que les autres font. (Et si un jour quelqu'un veut faire un site web similaire il aura déjà de bons outils disponibles)
|
Pour ce qui est des tests, il faut essayer d'à la fois tester les services (au niveau des fonctions appelées par les handlers) ET des fonctions simples utilitaires (tests unitaires). Le challenge, c'est de s'en sortir avec les datasets de tests et les mocks des services comme UVa. |
Tout est dans le titre... 😄
Je n'ai pas écrit de tests, bien que j'aie ajouté serverless-mocha-plugin aux dépendances. Les tests devraient selon moi être écrits par rapport aux différentes fonctions dans lib/platforms/uva.js (et pas par rapport aux différentes fonctions serverless) et je pourrai en écrire la plupart mais je ne suis pas sûr quant à l'architecture actuelle du code et je préfère que tu la reviewes d'abord.
Il faudra aussi rajouter des indexes à la base de données, mais ça je peux m'en occuper.