Entités serialisées en BDD
Alabate opened this issue · comments
Lorsqu'on enregistre une notification, le site sérialise l'objet dans la base de donnée pour pouvoir le lire au moment de l'affichage de la notification. L'avantage (ou pas) est que, même s'il y a eu des modifications après, il garde les informations du début.
Sauf que si, un jour, la structure d'une entité est amenée à changer. Symfony sera incapable de désérialiser automatiquement l'objet et nous affichera une belle erreur sur la page d'accueil des utilisateurs recevant la notification. Ce problème nous oblige à supprimer les notifications à chaque changement d'entité.
Pour moi, la solution est simple (dans le concept, pas forcément à mettre en place), il faut lier la notification avec un id d'entité plutôt.
Mais du coup, je me demande pourquoi ça n'a pas été fait comme ça au début ? Quelqu'un a une idée d'une raison spécifique ?
Edit: Une fois en prod, le nom de l'utilisateur n'est juste plus affiché, donc c'est moins grâve, mais c'est pas géniale non plus.
a commenté le bug Pas de mise à jour des évents
Edit: Bon en fait j'ai quand même tout supprimé, parce que j'avais des exceptions dans le log.
J'ai aussi pensé à remplacer par uniquement un 'id en lisant ton issue.
Ça a pu être fait pour des raisons de cache ou alors pour s'assurer d'afficher les informations du profil de l'utilisateur au moment où il a écrit le message ?
C'est pas que le profil qui est serialisé, c'est toute l'entité associé. Donc si je poste un event, et que j'ai fait une faute de frappe. Je peux modifier l'event, mais la faute de frappe restera la même dans la notif. C'est pas vraiment un avantage pour moi.
Je pense que la raison du cache est plus logique. Parce que quand on affiche la liste, ça veut dire qu'il ferais une requête par notification ? C'est plutôt lourd quand tu en as 10 à afficher.
Si c'est vraiment trop long, on pourrais faire un cache de la notification complète : Les notifications étant globales et pas personnalisées (la sélection est personnalisée, mais pas le contenu des notifs). En gros, dans l'idée, on rajoute deux champs à la table des notifs :
- Une version pré calculé de la notification (html)
- La dernière date de génération (ce qui nous permet de la régénérer tous les X)
Pour moi ça serait la solution la plus intéressante :)