On Tue, 9 Apr 2013 18:17:56 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Fri, 01 Mar 2013 15:14:57 +0100 Yannick Martel <martel@codelutin.com> wrote:
Salut ! ...
- persistence http://chorem.org/issues/885 (topia)
Je me demandais si la persistance NOSQL orientée document (MongoDB? Couchbase?) pourrait pas coller au modèle "vote" ? Je sais qu'on ne baigne pas dans ce paradigme, mais la souplesse et la "facilité" vu lors de conférence (JUG 2013 & Devoxx 2011), me laissent croire que ça peut coller...
Si on part dans le NoSQL, j'aurais peut-être dit plutôt une base orienté graph car il y a forcément des liens entres Votants/Votes/Choix/Sondages. Mais est-ce vraiment nécessaire de mettre beaucoup de nouvelle techno dans un projet qu'on souhaite voir aboutir ?
Si on fait déjà une api pure Rest avec UI en HTML/JS. Je pense qu'on aura assez de nouvelle chose qui nous ferrons perdre du temps. +1
Mais on peut toujours faire une petite réunion sur la persistance et une fois qu'on sait ce dont on a besoin voir celle qui nous permet de le mettre en oeuvre le plus facilement possible (le stockage ne sera pas un problème, mais la restitution pour le/les dépouillements doit-être le plus simple possible)
Je ne me souviens plus si je me suis déjà exprimé sur le sujet, mais je ne trouve vraiment aucun argument pour faire du NoSQL sur Pollen, c'est un peu comme si on venait me dire, pourquoi ne pas refaire Pollen en Python :(. donc +1 (pour ne rien changer) perso çe ne me parrait pas nécessaire, on a déjà pas beaucoup de temps à y consacrer, autant se focaliser sur les choses plus importante, à savoir les services et les ui. La seule chose importante pour moi c'est vraiment ça : service + UI.
...
Part-on dans l'idée de rester iso-fonctionnel, ou peut-on envisager d'y aller par etape, genre commencer à créer des sondages simples (oui/non et un total pour chaque choix) ? puis ensuite rajouter la complexité (Condorcet, pondération...)
Je pense que le but est de même faire plus. Mais pas forcément en une seule étape. Il vaut mieux faire une base qui fonctionne et ajouter les autres choses après.
Donc pendant quelques temps il y aura surement pollenOld et pollenNew en fonctionnement l'un a coté de l'autre.
Oui mais surtout il faudrait éviter de reproduire les erreurs du passé en repartant d'un existant qu'on modifie au fur et à mesure car on arrivera toujours aux limites des erreurs de conceptions originales, je pense ici vraiment au problème de la sécurité qui est la plus grosse limite actuelle pour continuer dans la même voie.
Pour ce qui est de dépouillement, peut-etre n'est-ce pas nécessaire, mais je verrais bien un module complètement indépendant de la persistance et de l'UI qui permette de faire le dépouillement. Ce module pourrait alors être réexploiter par d'autres pour du dépouillement, car il n'y a pas de librairie (il me semble) qui existe avec tout ce qui est déjà codé.
oui c'est déjà le cas, en quelque sorte, on a bien un module avec une API de dépouillement et chaque type de dépouillement a son module se basant sur cette API.
Si je ne me trompe pas c'est déjà un peu le cas. Donc avoir un dépouillement ou N ne doit demander que d'écrire et faire un peu plus de tests (différence entre 1 et N)
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com