Réunion du 12-03-2024

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.😉

Configuration

Configuration -- fichiers ini

• Si vous activez un module dans un fichier ini, vous devez aussi décommenter certaines choses ailleurs, certaines personnes n'y font pas attention.
• Techniquement, on peut tout regrouper dans une seule configuration, c'est ce que fait le système de toute façon. Avec les includes, on peut inclure n'importe quel texte et il sera chargé et remplacé en fonction de ce qui a été chargé en dernier.
• Les fichiers ini sont fusionnés dans un ensemble de configurations à part le fichier regions.ini
• Commandes de console permettant de voir la configuration en cours :

config get [<section>] [<key>]
Synonyme de config show

config show [<section>] [<key>]
Affiche les informations de configuration
Si aucune section ni aucun champ ne sont spécifiés, toute la configuration actuelle est imprimée.
Si une section est donnée mais pas de champ, tous les champs de cette section sont affichés.

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. La plupart des modules qui se connectent directement envoient du texte rouge, mais ne mettent pas fin à l'ensemble. Les modules qui ont des chaînes de connexion différentes pourraient ne pas lancer d'exceptions. 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, le schéma vérifie si la table a l'apparence voulue . 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.
• Le nouveau système vérifie si un fichier de migration existe pour modifier une table vers une nouvelle version. Il vérifie d'abord si la table n'est pas déjà à jour et applique ensuite la migration. La base de données devrait envoyer des codes d'erreur si la commande SQL échoue. Si le système obtient un code d'erreur, il se termine en indiquant à l'utilisateur qu'il doit corriger la table manuellement.
• Il faut comparer beaucoup de choses : les types de données, les dimensions, etc. (column_name,data_type,is_nullable,column_default,column_key,character_set_name,collation_name).
• 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.
• Vincent Sylvester aimerait connaître les avis/besoins des utilisateurs sur un choix qu'il a à faire :
  • Actuellement son code utilise l'ancienne migration puis utilise le nouveau système sur la migration.
  • Une autre possibilité serait d'utiliser directement le nouveau système sans passer par l'ancien.

Projets en cours / Infos

Versions d'OpenSimulator

Les versions release

• Elles sont identifiées par le seul numéro de version.
• Release actuelle [2] :

OpenSim.0.9.2.2 release

Version de développement

• Elles ont besoin du hash du commit pour une identification complète.
• Exemple de commit [3] avec hash = b70b5c07e3d0e32f28122be2b5e3d9d5c1f4b6a0. On prend que les 10 premiers caractères (b70b5c07e3).
• Les versions sur Osgrid indique aussi une heure.
• Exemple de nom de version de développement :

OpenSim 0.9.3.0 Nessie Dev b70b5c07e3 : 2024-03-11 00:18:05 0000 (SIM-0.3/0.8)

• La version 0.9.3.0 est donc encore en développement. Osgrid est une grille de test et utilise les versions de développement d'OpenSim.[4]

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-03-12