[Loterre-resolvers] create databases

[parmentf]

Le service web loterre-resolvers tel qu'il était écrit se mettait à jour une fois par semaine, pour chaque vocabulaire:

1. récupération du fichier SKOS
2. création d'une base contenant ses informations
3. création d'un index sur ces informations

Donc, à chaque première requête de la semaine (début de semaine tombant mardi), toutes ces opérations étaient relancées.
Cela menait parfois à un timeout, la création pour les plus gros vocabulaires pouvant prendre plus de 5 minutes.

Une première optimisation a consisté à intégrer directement à l'image du service tous les fichiers SKOS (ce qui évite leur téléchargement). Mais ce n'est pas la partie la plus longue: c'est la création de l'index.

Voir Inist-CNRS/web-services#46

Le mieux est donc de créer les fichiers de la base dans le dépôt Inist-CNRS/ws-data, et de pousser ces fichiers (compressés) sur un remote DVC.

On le fait vocabulaire par vocabulaire, pour pouvoir en ajouter ou en supprimer (ou simplement en mettre un seul à jour sans avoir à tout relancer).

[parmentf]

Le plus gros des vocabulaires provoque un timeout.
Je vais essayer en augmentant EZS_PIPELINE_DELAY qui a une valeur de 300 par défaut.

[parmentf]

Ça ne change rien.
Dans le doute, j'ai essayé avec node plutôt qu'avec bun, mais ça n'a rien changé.
Au bout de 6m4s, le message d'erreur est apparu (le même).
On dirait que EZS_PIPELINE_DELAY n'est pas pris en compte.

[parmentf]

Je m'étais trompé de vocabulaire.
Il a fallu monter EZS_PIPELINE_DELAY jusqu'à 1200 pour JVR (le Mesh).

Le problème suivant est de pouvoir récupérer les fichiers databases produits (en .tgz) du côté Inist-CNRS/web-services.
La création de pipeline implique que les fichiers sont suivis automatiquement par dvc, mais sans produire de fichier .dvc.
On ne peut pas ajouter à la main un de ces fichiers:

$ dvc add databases/216.tgz
ERROR: cannot update '216.tgz': overlaps with an output of stage: 'tgz-216' in 'dvc.yaml'.
Run the pipeline or use 'dvc commit' to force update it.

La seule méthode que je vois, c'est de prendre les informations nécessaires dans dvc.lock pour reconstruire des fichiers .dvc (à moins qu'on puisse faire un dvc pull à partir d'un dvc.lock?).

[parmentf]

Oui ! On peut récupérer des fichiers à partir de dvc.lock et dvc.yaml.

Ensuite, on peut faire dvc pull databases/D63.tgz.

[parmentf]

Le mieux, avec ce nouveau dvc.yaml, serait un dvc pull tgz (normalement, ça ne récupère que les sorties).