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