[analyse] Révision de la table Documents

[m-maillot]

Après plusieurs milliers de kms, il est temps de faire une révision à la table documents.

Kezako ?

C'est la table centrale de la base de données. Elle contient les informations qui seront disponibles en production.
Elle est composé d'un champ document contenant un json propre à chaque type de document. Celui ci est utilisé pour exporter la données sur ES. C'est le processus d'export qui se charge de transformer cette données en document ES.

Problématiques

• Table fourre tout
• Relationel faible
• Historique
• Bloque les évolutions (peu flexible)

Rôles attachés

1. Statut d'un document :

• [is_available] disponible ou non: alias supprimé
• [is_published] publié ou non: page disponible sur le site, utilisé historiquement pour des documents en cours de rédaction mais principalement pour retirer un document du site en cas de litige
• [is_searchable] disponible dans notre moteur de recherche

2. Mise à jour des documents

• [inital_id] liens vers les documents externes: permet à l'ingester de mettre à jour un document externe existant ou de le créer s'il n'exist pas ou de le rendre non disponible s'il n'existe plus. Utilisé également pour les documents en interne.

3. Lien + SEO du site

• [source + slug] url sur le site du CDTN
• [title + meta_description] meta données sur la site CDTN mais pas pour l'ensemble des documents, le front peut également surcharger la génération des données metas et générer ses propres données et certains types de documents contiennent cette information comme les pages infos, les contributions, les CCs et les modèles de courrier.

4. Thèmage du site

• [document_relations] contient les relations entre les documents.

5. Stockage des données

• [document] contient la données sur l'admin. Cela est vrai pour les dossiers, prequalifés, thèmes, page_fiche_ministere_travail, outils, highlights, code_du_travail et fiches_service_public. Les autres types de document disposent de leur propre table avec la données brutes. La table document étant là pour fournir la version publiée sur le site.

6. Snapshot des documents

Comme on peut la voir, la table document occupe pas mal de rôles au sein du projet. Trop de rôles qui la rendent peu flexible et complexifie pas mal de nouvelle fonctionnalité.

L'idée est de diminuer son rôle à un seul et unique rôle : avoir une version figée des documents à publier sur le site à un instant T.

[maxgfr]

+1

[maxgfr]

A noter : Il faudra repenser au feature de count document au niveau de l'export qui se base que sur le is_available: true et non sur le is_published: true

[carolineBda]

Supprimer le is_available serait une première étape. il faudrait d'assurer que les relations faites entre documents soit faites sur les initial_id et non sur les id des documents

[m-maillot]

Il faut revoir en premier les thèmes car à chaque fois on est bloqué.

• Lister les documents qui ont plusieurs thèmes
• Savoir si on peut avoir un thème par document
• Savoir si on garde les thèmes ?

Note: il y a des positions dans les thèmes.

Attention, il y a les préqualifiés qui font que l'on a des documents qui référencent des autres documents.

Sortir les préqualifiés pour après pouvoir attaquer les thèmes.

Voir pour le A la une.

[m-maillot]

Les conventions collectives ne sont pas thémés, on peut donc travailler pour les sortir de la table documents.

[m-maillot]

Analyse sur la table documents_relations.

La table comporte un champ type qui peut avoir 3 valeurs :

• theme-content
• document-content
• theme

Requête SQL :

SELECT DISTINCT type FROM document_relations;

On va analyser chaque type.

document-content

Ce type est utilisé pour les préqualifiés seulement. On a le document a (père) qui contient la préqualifié et ensuite le document b (enfant) qui contient le document dans la préqualifié.

Cette partie pourrait être extraite dans sa propre table.

Règles identifiés :

• Un document peut être dans plusieurs préaqualifiés

Requête SQL :

SELECT father.source as father_source, father.slug as father_slug, child.source as child_source, child.slug as child_slug FROM public.document_relations as dr INNER JOIN public.documents as father ON father.cdtn_id = dr.document_a INNER JOIN public.documents as child ON child.cdtn_id = dr.document_b WHERE type = 'document-content';

theme-content

Ce type est utilisé pour placer des documents dans un thème. On a le document a (père) qui contient le thème et ensuite le document b (enfant) qui contient le document dans le thème.

Règles identifiés :

• Un document peut faire partie de 2 thèmes. Actuellement, il y en a 35 en base de données.

Requêtes SQL :

SELECT father.source as father_source, father.slug as father_slug, child.source as child_source, child.slug as child_slug FROM public.document_relations as dr INNER JOIN public.documents as father ON father.cdtn_id = dr.document_a INNER JOIN public.documents as child ON child.cdtn_id = dr.document_b WHERE type = 'theme-content';

Documents référencés dans plus d'un thème :

with theme_content as (
SELECT father.source as father_source, father.slug as father_slug, child.source as child_source, child.slug as child_slug FROM public.document_relations as dr INNER JOIN public.documents as father ON father.cdtn_id = dr.document_a INNER JOIN public.documents as child ON child.cdtn_id = dr.document_b WHERE type = 'theme-content'
)

SELECT child_source, child_slug, COUNT(*) as duplicate_count
FROM theme_content
GROUP BY child_source, child_slug
HAVING COUNT(*) > 1;

theme

Ce type est utilisé pour construire la hiérarchie dans un thème. On a le document a (père) qui contient le thème et ensuite le document b (enfant) qui contient le sous thème.

Règles identifiés :

• Un thème fait partie de 2 thèmes (jeunes-travailleurs). Il n'y en a qu'un seul.

Requêtes SQL :

SELECT father.source as father_source, father.slug as father_slug, child.source as child_source, child.slug as child_slug FROM public.document_relations as dr INNER JOIN public.documents as father ON father.cdtn_id = dr.document_a INNER JOIN public.documents as child ON child.cdtn_id = dr.document_b WHERE type = 'theme';

Thèmes référencés dans plusieurs thèmes :

with themes as (
SELECT father.source as father_source, father.slug as father_slug, child.source as child_source, child.slug as child_slug FROM public.document_relations as dr INNER JOIN public.documents as father ON father.cdtn_id = dr.document_a INNER JOIN public.documents as child ON child.cdtn_id = dr.document_b WHERE type = 'theme'
)
SELECT child_source, child_slug, COUNT(*) as duplicate_count
FROM themes
GROUP BY child_source, child_slug
HAVING COUNT(*) > 1;

Thème contenu dans plusieurs thèmes :

SELECT father.source as father_source, father.slug as father_slug, child.source as child_source, child.slug as child_slug FROM public.document_relations as dr INNER JOIN public.documents as father ON father.cdtn_id = dr.document_a INNER JOIN public.documents as child ON child.cdtn_id = dr.document_b WHERE type = 'theme' and child.slug='jeunes-travailleurs';

[m-maillot]

To do sprint 54

Extraction des préqualifiés

L'idée est d'extraire les préqualifiés de la table document.

Etape 1 : Création d'une table prequalifié

Cette table doit contenir le texte de la préqualifié ainsi que les documents liés à cette recherche.

Etape 2 : Script de migration

Migrer les préqualifiés de la table document dans la nouvelle table

Etape 3 : Export dans ES

Modifier l'export dans ES pour utiliser la nouvelle table.

Voici le format attendu en sortie dans ES :

/!\ une particularité lié au contrib dans le code mais le code peut être gardé tel quel.

Etape 4 : Page pour visualiser / editer / supprimer

Etape 5 : Modifier alert-cli

L'alert-cli utilise les préqualifiés pour indiquer les contenus liés lors d'une modification. Le code est plutôt simple et utiliser pour les fiches sp et mt : https://github.com/SocialGouv/cdtn-admin/blob/add98324e06c3db9305b15c8d9c796ab8f94faa5/targets/alert-cli/src/diff/sp/getRelevantDocument/themesAndPrequalified.ts

[m-maillot]

Thème:

• Garder les thèmes
• Utiliser surtout backoffice pour catégoriser par thème
• Pas délirant dans les deux thèmes
• Deux niveaux minimum pour le technique

Première étape : Analyser l'utilité des thèmes sur le frontend. Etude pour la journée CDTN afin de valider si on garde ou supprime les thèmes du site.