Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create basic seeds committed in repo #1122

Open
adipasquale opened this issue Jan 19, 2024 · 1 comment
Open

create basic seeds committed in repo #1122

adipasquale opened this issue Jan 19, 2024 · 1 comment

Comments

@adipasquale
Copy link
Contributor

adipasquale commented Jan 19, 2024

the staging dump and upload to s3 process is overly complicated for maintenance mode

@adipasquale
Copy link
Contributor Author

adipasquale commented Jan 23, 2024

@bricedurand j’ai un peu réfléchi et je vois deux pistes

  1. seeds restreintes ~30 villes, ~100 objets
  2. seeds plus complètes toutes les villes de FR et tous les objets de Palissy

1. seeds restreintes

par ex

  • tous les départements (ça ne changera jamais)
  • seulement une dizaine de villes dans un des départements
  • quelques objets par ville
  • une ou deux villes dans des états de recensements différents (entamé, en attente d’examen, examinée)
  • éventuellement une campagne en cours dans un dept
  • si le/la dev veut des données plus proches de la prod, il/elle lance un import complet, ça devrait prendre une dizaine de minutes

Avantages :

  • ça permettra une maintenance simple : lors des modifs de schéma, on peut facilement changer ces seeds limitées en même temps qu’on écrit les migrations.
  • on pourrait même rajouter un test qui vérifie que les seeds sont à jour avec le schéma.
  • mieux que les seeds actuelles d’une certaine manière car on supprime tous les recensements et les campagnes sont bizarres apres import des seeds
  • Plus facile d’ajouter des cas dans les seeds (par ex une commune ayant examiné et avec un objet importé post-recensement)

Désavantages :

  • décalage avec les données réelles, on risque de coder des choses qui s’adaptent moins bien
  • potentiels bugs qui n’apparaissent qu’en dev (par ex un département sans villes)

2. seeds plus complètes

  • toutes les villes de FR
  • tous les objets de Palissy

Avantages

  • plus proche de la prod

Désavantages

  • fichiers CSV ou autres un peu lourds commités sur le repo git
  • il faut un peu maintenir à jour ces CSV dans le temps
  • maintenance moins simple
  • moins simple d’ajouter des cas spécifiques car il faut retrouver les communes et les objets dans les CSVs plutot que dans le code
  • dès qu’on veut importer une nouvelle colonne de palissy pour l’afficher dans CO (ou des infos sur les villes) il faudra mettre à jour les CSVs
  • il faut des nouveaux scripts pour générer les CSVs, ces scripts sont un peu doublons avec la synchro

Mon avis

je penche clairement vers la solution 1 seeds restreintes ça me parait plus simple, utile et facilement maintenable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant