Remarque : Ceci est adapté d’une conversation qui a eu lieu sur le Slack Make WP (voir le lien pour plus de contexte).
Notre situation actuelle concernant les miniatures
Les miniatures ont été collectées par les fournisseurs et placées dans la colonne thumbnail du catalogue. Nous y avons maintenant des données et la colonne n’a pas été supprimée. Comme cette colonne existe également dans l’API, les données qu’elle contient (pour l’audio comme pour les images) sont également copiées dans la colonne thumbnail à cet endroit. Cependant, seul le modèle Audio utilise la colonne thumbnail ; le modèle Image l’ignore et tente de créer une miniature réduite à l’aide de l’URL de l’image principale. La classe MediaStore du fournisseur a été modifiée afin qu’aucune nouvelle URL de miniature ne puisse être ajoutée à la colonne thumbnail, mais elles peuvent être ajoutées dans les métadonnées sous meta_data["thumbnail_url"].
Nous avons récemment rencontré des situations où nos propres tentatives de création de miniatures à partir des URL d’images en taille réelle ont provoqué des délais d’attente systématiques et empêché l’affichage des enregistrements dans les résultats de recherche. SMK en est un exemple récent : (1) (2). Il pourrait être avantageux d’utiliser, dans ces cas, les miniatures précalculées du fournisseur. Point crucial, tous les fournisseurs ne fournissent pas de miniatures et ne sont pas censés en fournir. Il semble donc que nous pourrions vouloir réduire la largeur de nos tables en supprimant cette colonne, souvent vide.
Proposition
Pour image : nous commençons par parcourir le catalogue et copier toutes les valeurs thumbnail existantes dans meta_data["thumbnail_url"]. Ensuite, nous effectuons un échange de table avec une nouvelle table sans la colonne et supprimons la colonne thumbnail de la table. Cela permettra d’économiser de l’espace et de réduire la largeur de la table. Nous mettons ensuite à jour la vue matérialisée image_view afin de remplir une colonne thumbnail pour l’APIAPI Une API, ou interface de programmation d’application, est un intermédiaire logiciel qui permet aux programmes d’interagir entre eux et de partager des données de manière limitée et clairement définie. à l’aide du dictionnaire meta_data. On en trouve un exemple dans la vue Audio audio_set_foreign_identifier. Cela nous permettra de conserver la colonne thumbnail dans l’API tout en réduisant l’espace utilisé dans le catalogue, car une migrationMigration Déplacement du code, de la base de données et des fichiers multimédias d’un site web d’un serveur vers un autre. Cela est généralement effectué lors d’un changement de société d’hébergement. de cette taille sur l’API serait probablement impossible à mettre en œuvre pour le moment. Nous apporterons ensuite deux modifications à la logique des deux côtés :
- Ajouter une logique de gestion de
thumbnail_urldansImageStore, qui placera automatiquement cette valeur dans le dictionnairemeta_data - Modifier la logique du modèle Image dans l’API afin qu’elle tente d’abord d’utiliser
image.thumbnail(qui a été copié depuismeta_data["thumbnail_url"]lors de l’actualisation des données), puisimage.urllors de la création de l’image réduite
Nous pourrions potentiellement faire de même pour Audio ; il semble qu’environ la moitié des enregistrements n’aient pas de miniatures :
deploy@localhost:openledger> select count(*) from audio where thumbnail is null;
+--------+
| count |
|--------|
| 427124 |
+--------+
SELECT 1
Time: 4.354s (4 seconds), executed in: 4.328s (4 seconds)
deploy@localhost:openledger> select count(*) from audio;
+--------+
| count |
|--------|
| 949384 |
+--------+
SELECT 1
Time: 3.899s (3 seconds), executed in: 3.887s (3 seconds)
Que pensez-vous de cette approche ? Je pense que tout effort visant à réduire la largeur de nos tables de base de données est important, car cela facilitera les migrations et la gestion des données à l’avenir.