#82 master.py : passer d'une logique stateless à statefull

Open
opened 6 months ago by Darks · 2 comments
Darks commented 6 months ago
Owner

Quand on exécute le script master.py, il exécute quoi qu'il arrive la suppression puis la création des assets qu'on souhaite : comptes par défaut, groupes, trophées, etc.

C'est problématique lorsque l'on veut ajouter un asset à la volée : les relations de la BDD sont déjà créées, donc on ne peut pas supprimer un item sans avoir à reconstruire intégralement la BDD.

L'idée est donc de regarder si les éléments existent, et pour ceux qui n'existent pas, les créer.

On a malheureusement pas d'ID unique sur les assets, donc si le nom d'un asset est modifié, un nouveau sera créé au lieu de modifier l'ancien. On doit pouvoir s'en sortir en ajoutant des ID à la main dans le yaml de config. À voir…

Ce mode de fonctionnement me parait intéressant y compris en prod, car on a de mémoire laissé tomber l'ajout de groupes/trophées via le panel admin web. Donc si il faut détruire la base de prod à chaque fois qu'on veut ajouter un truc, ça va être marrant ;)

Quand on exécute le script master.py, il exécute quoi qu'il arrive la suppression puis la création des assets qu'on souhaite : comptes par défaut, groupes, trophées, etc. C'est problématique lorsque l'on veut ajouter un asset à la volée : les relations de la BDD sont déjà créées, donc on ne peut pas supprimer un item sans avoir à reconstruire intégralement la BDD. L'idée est donc de regarder si les éléments existent, et pour ceux qui n'existent pas, les créer. On a malheureusement pas d'ID unique sur les assets, donc si le nom d'un asset est modifié, un nouveau sera créé au lieu de modifier l'ancien. On doit pouvoir s'en sortir en ajoutant des ID à la main dans le `yaml` de config. À voir… Ce mode de fonctionnement me parait intéressant y compris en prod, car on a de mémoire laissé tomber l'ajout de groupes/trophées via le panel admin web. Donc si il faut détruire la base de prod à chaque fois qu'on veut ajouter un truc, ça va être marrant ;)
Owner

Tout ça est juste. D'un autre côté le master script était à l'origine pensé vraiment que pour initialiser l'instance du site. L'idée initiale était de faire la maintenance via le site. Et il faut admettre qu'il y avait un flou considérable sur la période de développement, où on fait beaucoup plus de changements qu'en régime de croisière.

C'est peut-être le moment de se poser cette question. On a la migration Alembic pour le schéma de la bdd, et en effet rien du tout pour les contenus. Peut-être que le master script peut servir à ça. Mais dans ce cas je souhaiterais au moins séparer les fonctionnalités «d'initialisation» de celles «de maintenance». Sinon je valide l'idée générale.

Tout ça est juste. D'un autre côté le master script était à l'origine pensé vraiment que pour *initialiser* l'instance du site. L'idée initiale était de faire la maintenance via le site. Et il faut admettre qu'il y avait un flou considérable sur la période de développement, où on fait beaucoup plus de changements qu'en régime de croisière. C'est peut-être le moment de se poser cette question. On a la migration Alembic pour le *schéma* de la bdd, et en effet rien du tout pour les *contenus*. Peut-être que le master script peut servir à ça. Mais dans ce cas je souhaiterais au moins séparer les fonctionnalités «d'initialisation» de celles «de maintenance». Sinon je valide l'idée générale.
Darks added the
enhancement
label 6 months ago
Owner

Petite update puisque Darks me le fait remarquer sur la shout. Parmi les données manipulées par le script, certaines ne sont pas générées/réécrites :

  • Les membres sont listés uniquement pour pouvoir passer des gens admin et activer les mails.
  • Les propriétaires de trophées (qu'est-ce qu'ils font là ?).

Pour les données générées/modifiées :

  • Les forums sont mis à jour sans destruction, sauf si on change l'URL, qui sert d'identifiant, depuis 75f3a90f20. Si on veut changer les URLs, le plus safe est de faire groups update qui créera les forums en double, déplacer les topics vers les nouveaux forums en CLI avec flask shell, et supprimer les anciens. Je l'ai fait récemment, ça marche sans mauvaises surprises.

  • Pour les groupes et leurs permissions, pareil depuis c8661ca50f. L'identifiant est le nom (en français). S'il doit changer, faut faire pareil que pour les forums.

  • Les comptes communs sont encore supprimés à chaque fois. Mais d'un côté, on peut les modifier via l'interface du site, il n'y a pas de trop de raison de faire autre chose que les créer vides dans le master script.

  • Les trophées sont encore détruits avant d'être régénérés. Ça faudra le modifier.

Donc bon progrès, en gros y'a que les trophées à corriger et un nettoyage général à faire avec. Un peu tôt pour fermer mais on n'est pas loin. ^^

Petite update puisque Darks me le fait remarquer sur la shout. Parmi les données manipulées par le script, certaines ne sont pas générées/réécrites : * Les membres sont listés uniquement pour pouvoir passer des gens admin et activer les mails. * Les propriétaires de trophées (qu'est-ce qu'ils font là ?). Pour les données générées/modifiées : * Les forums sont mis à jour sans destruction, sauf si on change l'URL, qui sert d'identifiant, depuis https://gitea.planet-casio.com/devs/PCv5/commit/75f3a90f20d6439c4d134c699674a9b331247345. Si on veut changer les URLs, le plus safe est de faire `groups update` qui créera les forums en double, déplacer les topics vers les nouveaux forums en CLI avec `flask shell`, et supprimer les anciens. Je l'ai fait récemment, ça marche sans mauvaises surprises. * Pour les groupes et leurs permissions, pareil depuis https://gitea.planet-casio.com/devs/PCv5/commit/c8661ca50f1d7663d11ef61a9d7d96493fba0165. L'identifiant est le nom (en français). S'il doit changer, faut faire pareil que pour les forums. * Les comptes communs sont encore supprimés à chaque fois. Mais d'un côté, on peut les modifier via l'interface du site, il n'y a pas de trop de raison de faire autre chose que les créer vides dans le master script. * Les trophées sont encore détruits avant d'être régénérés. Ça faudra le modifier. Donc bon progrès, en gros y'a que les trophées à corriger et un nettoyage général à faire avec. Un peu tôt pour fermer mais on n'est pas loin. ^^
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.