Fermer

août 16, 2022

CMS optimisé – l’importance des GUID et des noms d’assemblage

CMS optimisé – l’importance des GUID et des noms d’assemblage


Dans le monde Optimizely CMS, nous voyons des GUID partout. Ce sont les identifiants uniques pour les types de contenu et plus encore. Dans le cadre du développement avec Optimizely CMS, il est conseillé aux développeurs de toujours spécifier les GUID dans leurs déclarations de type de contenu. Si aucun n’est spécifié, la base de données en attribue un dynamiquement lors de l’enregistrement du type de contenu.

Une grande raison à cela est que dans les coulisses, chaque fois que le code Optimizely recherche un type de contenu pour le rendu, il recherche d’abord par GUID. Si une correspondance est trouvée, ils récupèrent le contenu. Ils mettent même à jour certaines caractéristiques/propriétés de ce contenu si elles ont changé de code, afin de maintenir les données à jour.

Ce qui précède semble assez raisonnable et, heureusement, Optimizely a mis en place une solution de secours car lorsqu’un développeur oublie de mettre un GUID sur un type de contenu, la logique de sauvegarde s’en chargera. Mais est-ce que la même chose s’applique à d’autres choses comme les types de définition de propriété, par exemple ?

D’après une expérience de dépannage très récente, j’ai réalisé que ce n’était pas vrai dans tous les domaines. Les types de définition de propriété sont définis lorsque nous créons des PropertyLists. Ils ont une propriété GUID, mais pas obligatoire. De plus, aucun GUID n’est attribué dynamiquement au moment de la sauvegarde.

Qu’est-ce que ça veut dire?

Normalement, il n’y aura pas beaucoup d’impact. De manière optimale, CMS revient à la recherche par noms de type et noms d’assembly lorsqu’il n’y a pas de GUID à faire correspondre. Et comme les noms de type et d’assembly ne font pas partie de ceux que nous modifions assez souvent dans le code, cette correspondance renvoie toujours des résultats.

Le scénario où cela devenait problématique pour nous était la mise à niveau d’un site CMS 11 vers CMS 12. Notre site CMS 11 était déjà en ligne et en cours de développement. Nous n’avons donc pas directement voulu toucher à la même solution. Nous avons donc plutôt choisi de le cloner dans un nouveau référentiel, une nouvelle solution et de le mettre à niveau vers CMS 12. Pour une raison quelconque, nous avons fini par mettre un nom d’assemblage légèrement différent sur cette nouvelle solution. Et a également fini par refactoriser le code, déplacer des fichiers/dossiers pour une meilleure structure, modifiant ainsi les espaces de noms et techniquement les noms de type sur certains des types définis.

Comment ce changement nous a-t-il impacté ?

Eh bien, parce que nous ne comprenions pas exactement l’importance des GUID et des noms d’assembly à l’époque, nous ne nous sommes pas rendu compte que ces changements mineurs pourraient conduire à pratiquement casser des choses qui fonctionnaient auparavant comme la navigation et le menu, qui utilisaient largement les listes de propriétés.

Comme expliqué ci-dessus, notre Définitions de la liste des propriétés n’avaient pas de GUID spécifié sur eux. Alors maintenant, Optimizely s’appuyait sur l’utilisation des noms de type et d’assemblage pour trouver les types de définition de propriété. Et maintenant, dans notre nouvelle solution, ceux-ci ont également changé, donc en travaillant avec une copie de la base de données CMS 11 existante, il ne pouvait rien trouver pour la nouvelle combinaison de type et de nom d’assembly et ne pouvait donc pas afficher de données pour cela, ou le rendre. Et a continué à lancer cette étrange erreur de sérialisation json dans les journaux. Nous ne pouvions même pas enregistrer de nouvelles données sur ces listes de propriétés maintenant.

Épi de réponse d'erreur Json

Catégories Geta

Il en était de même pour Catégories Geta. Lorsque nous avons mis à jour le package Geta Category et lancé le site CMS 12, il a commencé à générer des erreurs pour ne pas trouver les types de catégories que nous avions créés dans le code. Lorsque nous avons regardé dans DB, nous avons vu que de nouvelles catégories avaient été créées avec le suffixe (1) pour tous les types que nous avions dans le code. Au départ, nous avons écrit des scripts SQL pour les nettoyer afin que ces erreurs disparaissent.

Mais après la découverte ci-dessus concernant les GUID et les noms d’assemblage, nous sommes revenus en arrière et avons examiné plus en profondeur les données. Fondamentalement, les catégories sont également des types de contenu, elles ont donc toujours un GUID, soit spécifié à partir du code, soit généré dynamiquement. Ils portent également le nom de type complet, qui contient le type et le nom de l’assembly. Et notre code avait également un GUID spécifié. Alors cela aurait dû fonctionner.

Catégories

Mais non. Apparemment, lorsque les catégories ont été créées pour la première fois, elles n’avaient pas de GUID spécifié dans le code. Ainsi, la base de données en a attribué un dynamiquement lors de la sauvegarde. Mais plus tard, quelqu’un est entré et a ajouté de nouveaux GUID dans le code à chacun d’eux. Mais cela ne correspondait pas à ce que la DB avait. Ainsi, lorsque Optimizely a essayé de faire correspondre le GUID, il n’a rien trouvé. Maintenant, il a essayé de faire correspondre ce nom de type complet, qui, grâce à nos modifications mineures de la solution CMS 12, avait également changé. Sans aucune correspondance, il en a créé de nouveaux, pensant que ce sont de nouveaux types. Et quand est venu le temps d’enregistrer le nom sur ceux-ci, car le nom d’origine existait déjà dans la base de données, la sauvegarde automatique a suffixé le nouveau avec (1). Alors maintenant, les endroits qui utilisaient ces catégories, ont trouvé la correspondance via GUID, ne pouvaient pas réellement correspondre au nom et donc se sont trompés.

Quelle était la solution ?

Une fois que nous avons réalisé ce qui s’était passé ici, nous avons apporté des modifications mineures mais très pertinentes pour résoudre non pas un mais plusieurs problèmes. Nous avons renommé l’assembly en ce que la solution CMS 11 avait, ajouté des GUID à nos définitions de liste de propriétés et fait correspondre le code et les GUID de base de données pour nos noms de catégorie et c’est tout. Tout s’est mis en place automatiquement. Le menu a commencé à fonctionner. Aucun nouveau type de catégorie n’a été créé. Plus d’erreurs de sérialisation json.

Propdef

Je sais que c’était un peu de narration, mais ce que j’ai compris de cet exercice, c’est que nous avons tendance à nous concentrer beaucoup plus sur les stratégies et les implémentations grandes, complexes, architecturales et de conception, que nous manquons parfois les petites choses. des choses granuleuses, qui sont petites, mais bien plus percutantes que nous ne le pensons. Les GUID et les noms d’assembly en sont deux exemples.

J’espère que cela sera utile pour les autres en cours de mise à niveau vers CMS 12 et qu’ils n’auront pas à passer autant de temps à comprendre cela que moi.






Source link