« Réunion du 12-03-2024 » : différence entre les versions
Aller à la navigation
Aller à la recherche
| Ligne 6 : | Ligne 6 : | ||
= Base de données = | = Base de données = | ||
=== Migration === | === Migration === | ||
====Fonctionnement | ====Fonctionnement actuelle de la migration ==== | ||
* Actuellement, si une migration échoue, tout continue comme si rien ne s'était passé.Rien ne s'arrête, l'échec est simplement signalé, c'est le feu et l'oubli. La migration s'exécute et tous les messages des modules de la console masquent les erreurs en quelques secondes. Ainsi, certaines grilles fonctionnent avec une combinaison d'échec de migration (partielle) et du bricolage des tables. | * Actuellement, si une migration échoue, tout continue comme si rien ne s'était passé.Rien ne s'arrête, l'échec est simplement signalé, c'est le feu et l'oubli. La migration s'exécute et tous les messages des modules de la console masquent les erreurs en quelques secondes. Ainsi, certaines grilles fonctionnent avec une combinaison d'échec de migration (partielle) et du bricolage des tables. | ||
* La migration n'est pas faite en transaction[https://fr.wikipedia.org/wiki/Transaction_informatique]. | * La migration n'est pas faite en transaction[https://fr.wikipedia.org/wiki/Transaction_informatique]. | ||
====Chaîne de connexion à la BDD ==== | |||
* La validité de la chaîne de connexion est la seule chose qui lève une exception. | * La validité de la chaîne de connexion est la seule chose qui lève une exception. | ||
====Nouveau système ==== | * S'il y a une erreur dans la chaîne de connexion ou si on tente de redémarrer la base de données alors qu'elle est toujours en cours d'exécution, l'arrêt n'est pas immédiat et certains modules tenteront de se connecter. Une gestion efficace de ce problème n'existe pas. Andrew Hellershanks a l’intention de se pencher sur la question. | ||
====Nouveau système de migration ==== | |||
* Vincent Sylvester a écrit un nouveau système qui migre chaque table plutôt que de partir de l'état des tables d'une version supposée. Pour le passage à une autre version, les tables présentes sont validées et les tables absentes sont directement créées (ndrl : si j'ai bien compris, je ne sais pas ce qui se passe avec les tables modifiées). Le plan est d'avoir un nouveau système qui stocke les informations de version dans les commentaires des tables pour chaque table et de les migrer et les valider à chaque étape. | * Vincent Sylvester a écrit un nouveau système qui migre chaque table plutôt que de partir de l'état des tables d'une version supposée. Pour le passage à une autre version, les tables présentes sont validées et les tables absentes sont directement créées (ndrl : si j'ai bien compris, je ne sais pas ce qui se passe avec les tables modifiées). Le plan est d'avoir un nouveau système qui stocke les informations de version dans les commentaires des tables pour chaque table et de les migrer et les valider à chaque étape. | ||
* Pour l'instant, Vincent Sylvester garde les anciennes données au cas où quelqu'un aurait encore besoin de les utiliser, après quoi la nouvelle migration prendra la relais. Elle se fera par table, par version, avec une validation après coup pour s'assurer que les tables sont conformes à ce à quoi elles devraient ressembler. Le principal point critique est de savoir s'il faut laisser l'ancien système en place ou faire l'effort de transformer les migrations existantes en migrations par table et utiliser le nouveau système pour tout. | * Pour l'instant, Vincent Sylvester garde les anciennes données au cas où quelqu'un aurait encore besoin de les utiliser, après quoi la nouvelle migration prendra la relais. Elle se fera par table, par version, avec une validation après coup pour s'assurer que les tables sont conformes à ce à quoi elles devraient ressembler. Le principal point critique est de savoir s'il faut laisser l'ancien système en place ou faire l'effort de transformer les migrations existantes en migrations par table et utiliser le nouveau système pour tout. | ||
Version du 15 mars 2024 à 12:36
Changements du code de la semaine
Avertissement
| Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉 |
Noyau
Scripts
Base de données
Migration
Fonctionnement actuelle de la migration
- Actuellement, si une migration échoue, tout continue comme si rien ne s'était passé.Rien ne s'arrête, l'échec est simplement signalé, c'est le feu et l'oubli. La migration s'exécute et tous les messages des modules de la console masquent les erreurs en quelques secondes. Ainsi, certaines grilles fonctionnent avec une combinaison d'échec de migration (partielle) et du bricolage des tables.
- La migration n'est pas faite en transaction[1].
Chaîne de connexion à la BDD
- La validité de la chaîne de connexion est la seule chose qui lève une exception.
- S'il y a une erreur dans la chaîne de connexion ou si on tente de redémarrer la base de données alors qu'elle est toujours en cours d'exécution, l'arrêt n'est pas immédiat et certains modules tenteront de se connecter. Une gestion efficace de ce problème n'existe pas. Andrew Hellershanks a l’intention de se pencher sur la question.
Nouveau système de migration
- Vincent Sylvester a écrit un nouveau système qui migre chaque table plutôt que de partir de l'état des tables d'une version supposée. Pour le passage à une autre version, les tables présentes sont validées et les tables absentes sont directement créées (ndrl : si j'ai bien compris, je ne sais pas ce qui se passe avec les tables modifiées). Le plan est d'avoir un nouveau système qui stocke les informations de version dans les commentaires des tables pour chaque table et de les migrer et les valider à chaque étape.
- Pour l'instant, Vincent Sylvester garde les anciennes données au cas où quelqu'un aurait encore besoin de les utiliser, après quoi la nouvelle migration prendra la relais. Elle se fera par table, par version, avec une validation après coup pour s'assurer que les tables sont conformes à ce à quoi elles devraient ressembler. Le principal point critique est de savoir s'il faut laisser l'ancien système en place ou faire l'effort de transformer les migrations existantes en migrations par table et utiliser le nouveau système pour tout.
- Le schéma est dans un fichier pour que ceux qui ont fait des changements dans les tables pour leur propre système puissent les éditer et faire en sorte que la validation réussisse.
Modules
Bugs
Tests
Projets en cours / Infos
Viewers
Source
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-03-12