-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ajout de l'historisation et des parents pour les buildings #270
Conversation
rappel pour moi-même : faire attention lors du merge, #266 rajoute un champ dans la table Building et il faut le rajouter dans la création de la table d'history, au bon endroit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Franchement c'est top. J'ai suggéré qq minis modifications dans models (rien de structurant)
La PR a aussi des conflits dans models |
Co-authored-by: Paul Etienney <paul@donatello.dev>
Co-authored-by: Paul Etienney <paul@donatello.dev>
L'extension initialement testée est une extension écrite en C et n'est pas disponible dans Scaleway (et n'est pas installable non plus).
Par chance, un autre projet a entrepris une réécriture en pur SQL et il est possible d'installer l'extension en exécutant des commandes SQL dans la base.
Cette PR ajoute une migration manuelle qui installe l'extension, créé la table d'historisation, active les triggers, ajoute un champ
tstzrange
à la table batid_buildings.J'en profite également pour ajouter un champ
parent_buildings
qui permettra de stocker la liste des buildings parents, ce qui sera utile quand on voudra tracer la filiation des éléments de cette table (en cas de merge de bâtiments par exemple). C'est plus facile de l'ajouter avant la création de la table d'historisation, pour qu'elle soit inclue dedans.