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

Darks commented

2020-10-31 10:27:02 +01:00

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 ;)

Lephenixnoir commented

2020-10-31 10:31:03 +01:00

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 2020-11-07 11:18:46 +01:00

Lephenixnoir commented

2021-03-15 21:53:50 +01:00

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. ^^

Lephenixnoir referenced this issue from a commit

2021-07-08 17:47:26 +02:00

master.py: reorganize commands (#82)

Lephenixnoir referenced this issue from a commit

2021-07-08 17:47:51 +02:00

master.py: update trophies in a lossless fashion (#82)

Lephenixnoir commented

2021-07-08 17:53:26 +02:00

Owner

Voilà avec ces changements tout est enfin nettoyé.

On notera que master.py reste le moyen préféré d'ajouter des trophées puisque c'est le seul qui donne accès aux icônes. L'interface web existe mais fait concurrence, et les changements de l'un écrasent l'autre. Je sais qu'on a changé de position plusieurs fois sur ce sujet, en tous cas pour l'instant seul le master script donne accès à tous les paramètres.

Voilà avec ces changements tout est enfin nettoyé. On notera que `master.py` reste le moyen préféré d'ajouter des trophées puisque c'est le seul qui donne accès aux icônes. L'interface web existe mais fait concurrence, et les changements de l'un écrasent l'autre. Je sais qu'on a changé de position plusieurs fois sur ce sujet, en tous cas pour l'instant seul le master script donne accès à tous les paramètres.

Lephenixnoir closed this issue

2021-07-08 17:53:26 +02:00

Darks commented

2021-07-08 17:59:08 +02:00

Author

Owner

IMHO les trophées sont des éléments qui n'ont pas vocation à changer régulièrement (demandent potentiellement du code coté backend). Donc je serais plutôt d'avis de dégager l'interface web. Ce qui permet au passage de rendre le truc plus ou moins traçable via les modifications du fichier yaml de référence.

Je reconnais faire un peu marche arrière sur le sujet, mais de l'autre coté le rôle du master script a légèrement évolué entre temps, et permet de prendre en charge plus sereinement ce type d'évolutions ^^

IMHO les trophées sont des éléments qui n'ont pas vocation à changer régulièrement (demandent potentiellement du code coté backend). Donc je serais plutôt d'avis de dégager l'interface web. Ce qui permet au passage de rendre le truc plus ou moins traçable via les modifications du fichier yaml de référence. Je reconnais faire un peu marche arrière sur le sujet, mais de l'autre coté le rôle du master script a légèrement évolué entre temps, et permet de prendre en charge plus sereinement ce type d'évolutions ^^

Lephenixnoir commented

2021-07-08 18:26:43 +02:00

Owner

Va pour supprimer l'interface web si ça ne te gêne pas. Je trouve aussi que c'est plus simple de passer par le script (parce qu'effectivement de toute façon il faut modifier le code pour attribuer les trophées...).

Eragon commented

2021-07-08 18:39:51 +02:00

Member

L'interface web me semble inutile, j'avais même oublié son existence tellement elle me semblait inutile. Ça peut être pratique pour corriger une typo, comme je l'ai fait dans le yaml mais il faudrait de toute façon reproduire la modification dans le fichier a un moment ou un autre.

Lephenixnoir referenced this issue from a commit

2022-05-26 22:26:01 +02:00

admin: remove trophy edition interface (#82)

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