-
Notifications
You must be signed in to change notification settings - Fork 10
ModuleBase
Base est un module particulier, dans le sens ou il ne s'agit pas de fichiers installés effectivement sur le serveur, mais plutôt de tout ce qui permet de constituer ou reconstituer la base de donnée.
- Les schémas d'origine sont contenus dans le répertoire schema. NB: Ce sont des export de décembre 2008.
- Voir (mais donc pas complètement à jour) http://dev.virtual-loup-de-mer.org/vlm/browser/trunk/base/README.txt)
-
Voir http://wiki.virtual-loup-de-mer.org/index.php/Proposer_des_courses pour une approche pratique
-
la table races_ranking contient une photo la plus récente des positions et métrologie d'un bateau pour une course donnée (nb : il n'y a pas - encore - d'historisation).
VLM a été conçu à l'origine pour une association un joueur un bateau. La table users est donc la liste des bateaux connus, en course ou pas. On retrouve partout dans le code la notion d'idusers (ou idu) : qui désigne un bateau et non un joueurs
Les préférences des bateaux (users) non indispensables au fonctionnement du site (paramètres de cartes, ...) sont gérées dans la table user_prefs pour la plupart. Certaines (pavillon, blocnote, etc...) sont encore gérées dans la table users directement, mais cela doit évoluer.
Les bateaux réels (ceux des vraies courses) sont actuellement gérés comme des bateaux dont l'idusers est < 0.
C'est une limitation du modèle d'origine a vers une [wiki:playermodele gestion de plusieurs bateaux pour un même compte].
C'est la table players qui le prends en charge.
Avant d'être créé un player passe par la table intermédiaire playerspending pour validation de son email.
La table players2users fait le lien entre les bateaux et les joueurs, en lui associant un type (relationtype), qui peut être BOATSIT (2) ou OWNER (1).
Les préférences des joueurs non indispensables au fonctionnement du site (langue, moyen de contact, etc...) sont gérées dans la table players_prefs
Quand on travaille sur le serveur de test, on peut avoir besoin de modifier le schema/le contenu de la base de données. La difficulté vient plus tard, quand il s'agit de mettre en production cette modification (de mettre à jour le vrai serveur mysql de vlm).
Le fichier UPDATE contient l'historique des modifications faites manuellement à la base mysql de test. Ces modifications sont à prendre en compte au moment du déploiement en production d'une nouvelle version. Le remplir est important...
Pour les modifications les plus courantes, le fichier UPDATE ne contient maintenant que l'instruction pour utiliser le répertoire scripts (voir plus bas)
Il contient les scripts de base :
- dump.sh : pour faire un dump de la base de donnée
- importdump.sh : pour importer le dump
- init.sh : pour créer la base
Il contient aussi les méthodes automatiques pour le changement de version :
- runupgrade.sh : est le script qui prend en paramètre la version (exemple : v0.11
- upgrade-v0.11.php et upgrade-v0.11.sql (par exemple) sont les 2 scripts qui seront appelés par
runupgrade.sh v0.11
Pour préparer/documenter un changement du modèle de base de donnée :
- les fichiers upgrade-vXXX.sql contiennent les instructions sql d'altération de la base (exécuté en premier)
- les fichiers upgrad-vXXX.php contiennent les instructions complémentaires en php éventuellement nécessaire pour migrer les données dans un nouveau modèle.
- par exemple, il était nécessaire d'utiliser php quand il a fallut insérer en base toutes les images de cartes jusqu'ici fichiers statiques.