Gestionnaire de mises à jour

L'installation permet à l'utilisateur d'installer la dernière version de votre logiciel. En effet, il est inutile d'installer une version antérieure pour ensuite devoir effectuer une MàJ.

L'installation peut être gérée par un programme spécifique (souvent setup.exe).

Dans ce cas-là, on peut soit demander à l'utilisateur de lancer lui-même ce programme, soit d'offrir la possibilité à l'utilisateur d'installer le logiciel via le gestionnaire de MàJ qui lancera lui-même l'installateur.

Trois méthodes s'offrent alors à vous :

• soit vous intégrez toutes les ressources dans le setup ce qui permettra une installation hors ligne mais en contrepartie, le setup.exe sera lourd et vous n'installerez pas forcément le dernier logiciel ;
• soit le setup va rechercher les ressources sur Internet, nous serons alors sûrs d'obtenir la dernière version du logiciel, le setup sera plus léger mais vous ne pourrez pas faire d'installation hors ligne ;
• soit vous faites un mixte des deux, en mettant tout ou partie des ressources dans le setup puis en téléchargeant les ressources manquantes tout en mettant à jour certains fichiers (la méthode diff et patch est très appropriée dans cette situation). Dans ce cas-là, on préférera souvent mettre dans le setup les fichiers stables ainsi que les fichiers indispensables à l'utilisation hors ligne du logiciel et on téléchargera les fichiers instables ou non indispensables au fonctionnement hors ligne du logiciel.

Mais l'installation peut aussi se faire directement par le gestionnaire, une installation peut alors être considérée comme une mise à jour d'une version 0 (version vide) à la version actuelle.

La désinstallation permet à l'utilisateur de supprimer toute trace de votre logiciel.
L'utilisateur peut être amené à y recourir s'il n'est pas satisfait de votre création, s'il n'en a plus l'utilité ou s'il ne compte plus utiliser ce logiciel sur un ordinateur particulier.

III-A-2-a. Méthode bourrin▲

III-A-2-b. Méthode prudente▲

III-A-3-a. Le problème▲

III-A-3-b. La solution▲

Pour permettre l'abandon d'une MàJ en cours d'exécution, il nous faut deux threads : l'un pour la lecture des événements clavier et l'un pour la MàJ.

Mais en cas d'arrêt de la MàJ, nous aurons une version « hybride » une version qui sera entre la version du client (X) et la version actuelle (Y) et qui ne sera ni X, ni Y.

Il faut donc s'assurer qu'au prochain redémarrage du gestionnaire, que la MàJ se poursuive ou au pire, que la MàJ permette l'acquisition d'une version Y complète.

Lorsque la MàJ est interrompue par l'utilisateur (ou par un événement externe), nous pouvons toujours enregistrer le numéro de version X, le numéro de version Y ainsi que le n° de la dernière instruction traitée afin de reprendre la MàJ où elle s'était arrêtée. Mais le plus important est de faire en sorte de modifier le numéro de version du client telle qu'elle est perçue par le gestionnaire uniquement à la toute fin de la mise à jour.

Ordinogramme représentant une MàJ : afin d'éviter d'interrompre brutalement la MàJ (ce qui laissera l'arborescence des fichiers dans un état indéterminé) on attendra la fin de chaque instruction pour traiter l'abandon de la MàJ

Souvent, les gestionnaires de MàJ de jeux affichent des news.

On peut intégrer un navigateur internet ouvrant une page spécifique dans un cadre du gestionnaire mais l'intégration d'un navigateur internet est très lourde, on préférera donc très souvent télécharger des fichiers dédiés aux news et à leur affichage (format XML, TXT…).

On peut aussi télécharger une ou plusieurs images qu'on affichera ensuite directement.

Le gestionnaire peut supprimer/regarder/modifier n'importe quels fichiers sur le disque du client.
Pour éviter cela, avant chaque action, on regardera si le chemin ne contient pas './' et qu'il ne commence ni par '/', ni par '~' (ni par ''?:\'' pour Windows) pour éviter qu'on puisse toucher aux fichiers qui ne seraient pas dans le dossier du logiciel.

Il peut arriver que l'utilisateur supprime ou modifie des fichiers.

Pour résoudre le problème des fichiers supprimés, il faudra, pendant la mise à jour, voire à chaque exécution du gestionnaire, vérifier que tous les fichiers nécessaires existent.

Le problème des fichiers modifiés est un peu plus complexe.

On peut tester chaque fichier et remplacer ceux qui ont été modifiés, mais comment savoir si le client souhaite ou non que sa modification soit annulée ?
On peut décider que le client n'a pas à modifier ces fichiers (éventuellement à l'exception de certains fichiers).

Mais il faut bien être conscient que le gestionnaire ne peut vous garantir que les fichiers seront intacts lors de leur utilisation. Pour cela, il vous faudra lancer un logiciel qui vérifiera l'état de vos fichiers en même temps que s'exécutera votre programme.

Nous pouvons aussi considérer que les modifications ne posent pas de problème et que l'utilisateur est responsable de ses actes. Si la modification pose problème, on laissera l'utilisateur supprimer le fichier afin qu'il puisse être retéléchargé au prochain lancement du gestionnaire.

Afin de résoudre le problème lié à la suppression des fichiers par l'utilisateur, il faut vérifier la présence de ces fichiers. Tant qu'il n'y a pas de MàJ, on ne se pose pas vraiment la question, mais dans le cas contraire, quand faut-il faire cette vérification ?

• Avant la MàJ ? Mais dans ce cas-là, on risque de rétablir des fichiers qui seront supprimés pendant la MàJ.
• Après la MàJ ? On va devoir alors vérifier la présence de tous les fichiers, même ceux qui viennent juste d'être téléchargés. De plus, la suppression d'un dossier risque de poser problème, en effet, certaines opérations comme l'ajout de fichiers dans ces dossiers risquent d'être compromises.

La meilleure solution est d'intégrer les vérifications à la MàJ, on vérifiera donc la présence de tous les fichiers inchangés ainsi que d'autres fichiers dont l'absence pourrait poser problème lors de la MàJ. On préférera donc vérifier la présence d'un fichier juste avant sa première utilisation par le gestionnaire.

Lorsqu'aucune MàJ ne sera disponible nous ferons donc une « miniMàJ » dans le but de restaurer tous les fichiers supprimés.

Nous avons vu que nous avons besoin de connaître la version du client pour effectuer une MàJ, mais comment connaître la version X du client ?

On peut décider de stocker la version du client dans votre logiciel, on récupérerait alors la version en l'appelant avec un argument spécial et il nous écrira la version sur sa sortie standard. Il est ainsi plus difficile de changer artificiellement la version perçue par le gestionnaire mais ceci implique de devoir mettre à jour l'exécutable à chaque MàJ. Ceci peut devenir très lourd surtout si la MàJ ne touche que des petits fichiers et que l'exécutable est assez volumineux.

Il est aussi possible d'enregistrer la version du client dans un fichier. Mais si l'utilisateur supprime ce fichier, on considérera qu'il possède une version 0, il provoquera donc une réinstallation du logiciel. Mais s'il écrit dedans, il risquera d'avoir des fichiers non mis à jour.

On peut aussi mettre la version dans le nom de l'exécutable (ex. : mon_programme_v0.15.exe) mais ceci nécessitera de mettre tous les raccourcis vers cet exécutable à jour. Or si l'utilisateur a créé ses propres raccourcis, il sera forcé de les modifier un à un.

Certaines personnes vont essayer de déterminer la version du client grâce au poids des fichiers et de leurs dates de création. Bien que cette méthode marche assez souvent, elle n'est pas très fiable (on ne sait jamais ce que l'utilisateur va faire) et est plus lente que d'autres méthodes plus simples.

Dans le cas du stockage de la version dans un fichier, l'utilisateur modifie la ''perception'' de la version du client par le gestionnaire en toute conscience, on le juge donc responsable de ses actes sur un tel fichier. Tandis qu'avec la méthode précédente, si l'utilisateur effectue une modification quelconque, il ne sera pas conscient de modifier la version perçue.

On utilisera de préférence la version du fichier

Dans certains cas, il est nécessaire de conserver plusieurs versions des fichiers voire du logiciel, pour permettre à l'utilisateur de continuer à utiliser une ancienne version de votre logiciel si jamais la nouvelle version ne fonctionne pas chez lui.

On peut alors soit conserver toutes les versions côté client ou conserver des versions spécifiques (toutes les X.0 versions par exemple), dans ce cas-là, il faudra mettre en place côté serveur une gestion des différentes versions des fichiers.

On peut aussi décider de conserver uniquement les versions que l'utilisateur a utilisées et dans ce cas-là, il est inutile de conserver d'anciennes versions des fichiers côté serveur.

Mais dans les deux cas, il faudra, côté client, conserver différentes versions d'un même fichier.

Pour ceci un simple dossier portant le nom de la version et contenant tous les fichiers ayant été modifiés ou ajoutés par cette version. C'est-à-dire qu'une version d'un fichier (à ne pas confondre avec la version du logiciel) ne sera stockée qu'une seule fois dans le dossier de la version où il est apparu pour la première fois. L'exécutable de la version X va donc rechercher dans le dossier X les éléments nécessaires et s'il ne les trouve pas, il ira rechercher dans une version antérieure, jusqu'à les trouver.

Un simple serveur Web suffit, il faudra juste une interface en PHP ainsi qu'une base de données, ce qui reste relativement assez facile à trouver gratuitement.
Dans ce cas-là, on utilisera l'interface PHP pour administrer nos versions et le gestionnaire lira une page Web qui transmettra les instructions à effectuer. Il ne faut en aucun cas que ce soit le gestionnaire qui se connecte directement à la BDD à moins de créer et d'utiliser un compte « public » où seule la lecture est autorisée.
La page PHP peut déterminer elle-même les instructions à effectuer lors de la MàJ, mais on peut aussi décider qu'à chaque nouvelle MàJ, on détermine puis on enregistre toutes les séquences d'instructions pour chaque version. La page PHP devra alors juste afficher le contenu du fichier approprié.

Il est aussi possible d'utiliser un serveur dédié, on s'orientera alors souvent vers un programme côté serveur en C ou C++ voire en Java ce qui permettra d'être plus rapide.
Il y a alors deux solutions, soit on établit des sockets, soit on utilise des fichiers cgi.

Héberger les données en P2P semble plutôt intéressant car ceci permet de décharger son serveur de multiples téléchargements ainsi qu'aux utilisateurs de télécharger plus rapidement nos fichiers.

Il existe trois réseaux en P2P :

• centralisé : un serveur unique, il ne représente donc aucun intérêt ici ;
• distribué : chaque utilisateur donne de sa bande passante et joue le rôle de serveur mais il faut que chaque utilisateur de votre logiciel accepte de donner une partie de sa bande passante. De plus nous sommes en plus confrontés à des problèmes de sécurité surtout si vous distribuez votre logiciel en open source. En effet, rien n'empêchera un utilisateur de distribuer une version corrompue de votre logiciel. Les autres utilisateurs l'installeront automatiquement en mettant à jour leurs versions sans se douter de rien.
• hybride : il y a plusieurs serveurs et un utilisateur peut devenir serveur s'il le souhaite et sous certaines conditions. Mais ce système n'est pas simple à mettre en place et ne résout pas les problèmes de versions corrompues.

En conclusion, le P2P est une ''fausse bonne idée'' car il est peu fiable pour cette utilisation.

Il est possible de régler le problème des versions corrompues en proposant un serveur qui donnera pour chaque fichier, ainsi que sa version, son hash afin de pouvoir vérifier chaque fichier téléchargé.

Dans la suite du tutoriel, nous donnerons surtout des instructions SQL afin de rester le plus général possible.

Pour réduire les flux entre le serveur et le client, il n'y a pas beaucoup de solutions.

Il faut déjà essayer de supprimer tous les flux inutiles comme l'envoi d'un fichier que le client possède déjà.

Ensuite, on peut compresser au maximum les archives envoyées au client, mais ceci nécessite de devoir les décompresser côté client.

Certains pourront penser à utiliser des sockets UDP pour télécharger les fichiers, mais nous n'aurons alors aucune garantie que nos fichiers arrivent intacts et dans l'ordre à destination.

III-C-3-a. Problématique▲

III-C-3-b. Informations nécessaires▲

III-C-3-c. Table BDD▲

Pour plus de rapidité dans les traitements, nous rajouterons aussi un attribut Etat qui prendra ces valeurs :

• N : n'est pas la dernière position du fichier ;
• O : dernière position du fichier ;
• T : prochaine position du fichier lorsque la prochaine version en cours sera finie ;
• P : ne sera plus la dernière position du fichier lorsque la prochaine version en cours sera finie.

Requêtes SQL pour la création des tables :

Création des tables

Sélectionnez

/* on supprime les tables si elles existent déjà */
DROP TABLE POSITION ;
DROP TABLE FICHIER;
DROP TABLE VERSION;

/* on crée les tables en ajoutant des contraintes de colonnes et de tables afin d'être sûr de garder une table valide quoi qu'il se passe. */
CREATE TABLE VERSION (id MEDIUMINT PRIMARY KEY AUTO_INCREMENT, Version VARCHAR(20) NOT NULL, Active CHAR(1) NOT NULL CHECK Active IN ('O', 'N'), CHECK(Version <> '0')) ;

CREATE TABLE FICHIER (id MEDIUMINT PRIMARY KEY AUTO_INCREMENT, Version_creation MEDIUMINT NOT NULL REFERENCES VERSION.id, Version_suppression MEDIUMINT REFERENCES VERSION.id, Version_maj MEDIUMINT REFERENCES VERSION.id, Version_futur_maj MEDIUMINT REFERENCES VERSION.id, Source  VARCHAR(200), CHECK(Version_suppression IS NULL OR Version_suppression > Version_creation), CHECK((Version_suppression IS NOT NULL AND Version_maj IS NULL) OR Version_suppression IS NULL), CHECK (Version_maj IS NULL OR Version_maj > Version_creation), CHECK((Source IS NULL AND Version_maj IS NULL AND Version_futur_maj IS NULL) OR Source IS NOT NULL)) ;

CREATE TABLE POSITION (id_Fichier MEDIUMINT NOT NULL REFERENCES FICHIER.id, id_Version MEDIUMINT NOT NULL REFERENCES VERSION.id, Nom VARCHAR(100) NOT NULL, id_dossier MEDIUMINT REFERENCES FICHIER.id, Derniere_position CHAR(1) NOT NULL CHECK Derniere_position IN ('O', 'N', 'T', 'P'), PRIMARY KEY(id_Fichier, id_Version), CHECK(id_Fichier <> id_dossier));

/* on crée la version 0 (version vide) */
INSERT INTO VERSION VALUES('', '0', 'O');

Il ne faut pas oublier de créer la version 0.

Pour passer d'une version à une autre, le gestionnaire va devoir effectuer des actions en fonction des instructions qui lui sont données, voici une liste de différentes instructions possibles :

• supprimer un fichier ;
• supprimer un fichier du gestionnaire ;

• supprimer un dossier vide ;
• supprimer un dossier vide du gestionnaire ;
• créer un dossier ;
• créer/mettre à jour un fichier * ;
• mettre à jour un fichier du gestionnaire * ;
• déplacer/renommer un fichier ou un dossier ° ;
• déplacer/renommer un fichier ou un dossier du gestionnaire ° ;
• vérifier la présence d'un fichier *.

Tous nécessitent de connaître le chemin des fichiers du client.

* nécessite de connaître le chemin de la ressource à télécharger.

° nécessitent de connaître le chemin de destination.

Pour mieux comprendre ce que devra faire chacune de ces fonctions, voici un ordinogramme donnant les différentes actions exécutées lors du traitement d'une instruction :

Maintenant que nous connaissons quelques instructions, il faut encore déterminer une séquence d'instructions correcte afin d'éviter toute erreur lors de la MàJ comme l'ajout d'un fichier dans un dossier pas encore créé.

Les dossiers se distinguent des fichiers par un attribut source NULL

Soit X l'identifiant de la version de l'utilisateur et Y celui de la nouvelle version.

L'algorithme reste assez simple à comprendre, j'ai mis le code SQL nécessaire à l'acquisition des informations nécessaires à l'écriture des instructions.

En utilisant les noms des fichiers de la version X :

• on supprime tous les fichiers où la version de suppression > X et dont la version de création < X :

/* sélection du nom et de l'identifiant du dossier contenant le(s) fichier(s) à supprimer. */
SELECT nom, id_dossier FROM POSITION WHERE Derniere_position = 'O' AND id_Fichier IN(SELECT id FROM FICHIER WHERE Version_suppression IS NOT NULL AND Version_suppression > Y AND Version_creation < X Source IS NOT NULL)

• on crée tous les dossiers où la version de création > X et dont la version de suppression n'est pas renseignée :

/* sélection du nom et de l'identifiant du dossier contenant le(s) dossier(s) à créer. */
SELECT nom, id_dossier FROM POSITION WHERE id_Fichier IN(SELECT id FROM FICHIER WHERE Version_creation > Y AND Version_suppression IS NULL AND Source IS NULL);

Attention à l'ordre de création des dossiers, pour éviter tout problème, on préférera souvent établir temporairement un arbre contenant tous les nouveaux dossiers ainsi que leurs dossiers parents.
À chaque ajout d'un dossier à cet arbre, on testera sa présence si elle n'est pas évidente.
Ensuite, il suffira d'ajouter les dossiers en faisant un parcours en profondeur de l'arbre.

On utilisait jusqu'à présent les anciens noms des dossiers, on va désormais utiliser les deux.

• On déplace/renomme tous les dossiers où la version de dernière position > X et dont la version de suppression n'est pas renseignée en triant les dossiers par id décroissant :

/* sélection du nom, de l'identifiant et de l'identifiant du dossier qui contiendra le(s) dossier(s) à déplacer. */
SELECT nom, id_dossier, id_Fichier FROM POSITION WHERE id_Version > X AND Etat = 'O' AND id_Fichier NOT IN (SELECT id FROM FICHIERS WHERE Version_suppression > X AND source IS NULL) ORDER BY id_Fichier ASC;

Lorsqu'on recherchera le chemin de ce dossier, on utilisera l'ancien nom de dossier si l'id du dossier est > à l'id du dossier en cours sinon, on utilisera le nom de la version Y.

Lorsqu'on déterminera le chemin source ainsi que le chemin de destination, il ne faut pas oublier d'ajouter tous les dossiers qui ne sont pas encore dans notre arbre temporaire et aussi de déplacer les dossiers au sein de notre arbre au fur et à mesure qu'on déplace nos propres dossiers.

Maintenant, on n'utilise que les noms de la version Y.

• On déplace/renomme tous les fichiers de version de dernière position > X et dont la suppression n'est pas renseignée :

/* sélection du nom, de l'identifiant et de l'identifiant du dossier qui contiendra le(s) dossier(s) à déplacer. */
SELECT nom, id_dossier, id_Fichier FROM POSITION WHERE id_Version > X AND Etat = 'O' AND id_Fichier NOT IN (SELECT id FROM FICHIERS WHERE Version_suppression > X AND source IS NOT NULL);

Nous inclurons aussi ces fichiers dans notre arbre temporaire.

• On supprime les dossiers dont la version de suppression est > X :

SELECT nom, id_dossier FROM POSITION WHERE Derniere_position = 'O' AND id_Fichier IN(SELECT id FROM FICHIER WHERE Version_suppression IS NOT NULL AND Version_suppression > X AND Source IS NULL)

• On crée les fichiers dont la version de suppression est > X et dont la version de suppression n'est pas renseignée :

/* sélection du nom, de la source et de l'identifiant du dossier contenant le(s) fichier(s) à créer. */
SELECT POSITION.nom, POSITION.id_dossier, FICHIER.source FROM POSITION, FICHIER WHERE POSITION.id_Fichier = FICHIER.id AND FICHIER.Version_creation X AND FICHIER.Source IS NOT NULL AND FICHIER.Version_suppression IS NULL AND Etat = 'O';

• Et enfin, on parcourt en profondeur notre arbre temporaire en même temps que l'arborescence de la version Y et on rajoute tous les fichiers manquants.
  

Comme vous pouvez le voir, ces instructions ne sont pas évidentes, d'où l'importance du précalcul. Plutôt que de tout recalculer dès qu'un client veut mettre à jour son logiciel, on va , lors de la création d'une version, enregistrer pour chaque version, les instructions à effectuer.

Maintenant que nous savons comment déterminer une séquence d'instructions pour mettre à jour une version donnée de votre logiciel, il nous manque encore à ajouter de nouvelles versions au serveur.

L'administration des versions sera similaire à ceci :

L'Administrateur (admin sur le schéma) utilisera une interface pour générer des fichiers d'instructions à partir des informations stockées dans la BDD (Base De Données). Les fichiers d'instructions devront aussi connaître l'URL des fichiers sources à télécharger par le client.

Là encore, il y a plusieurs méthodes comme de comparer une archive comprenant l'ensemble des fichiers de la nouvelle version du logiciel avec l'archive de la version précédente afin de déterminer les modifications qui ont été ajoutées. Mais cette méthode ne fera pas de lien entre deux versions différentes d'un fichier. Il faudra aussi comparer tous les fichiers de la version précédente avec ceux de la nouvelle version pour détecter les déplacements. De plus il n'est pas toujours évident qu'il puisse détecter correctement les déplacements de dossier.

Soit X le nombre de fichiers de la version précédente et Y celui de la nouvelle version, il faudra faire X*Y comparaisons.

Je préfère plutôt permettre au développeur de partir de la version précédente puis de modifier lui-même cette version pour donner la version actuelle. C'est certes plus long mais ceci permettra de pouvoir observer l'évolution de chaque fichier et de voir lesquels sont plutôt instables et lesquels sont plutôt stables.

Il faudra donc que le développeur puisse :

• créer une nouvelle version : cette version devra être inactivée afin de ne pas mettre à jour avec une version incomplète les clients qui lanceraient leur gestionnaire pendant que nous finissons cette version :

INSERT INTO VERSION VALUES(NULL, $nom_version, 'N')

• voir l'arborescence de la nouvelle version : de base, elle sera identique à celle de la version précédente, il faudra donc que le développeur modifie cette arborescence pour créer la nouvelle version, on utilisera alors une fonction récursive pour l'affichage :

/* sélection des informations fichiers sur les éléments présents à la racine de l'arborescence */
SELECT * FROM FICHIER, POSITION WHERE FICHIER.Version_suppression IS NULL AND POSITION.Derniere_position IN ('O', 'P') AND POSITION.id_Fichier = FICHIER.id AND POSITION.id_dossier IS NULL;
/* sélection des informations fichiers sur les éléments contenus dans le dossier d'identifiant $id_dossier */
SELECT * FROM FICHIER, POSITION WHERE FICHIER.Version_suppression IS NULL AND POSITION.Derniere_position IN ('O', 'P') AND POSITION.id_Fichier = FICHIER.id AND POSITION.id_dossier = $id_dossier;

- construire une nouvelle version à partir de cette dernière version (création, suppression, déplacement, MàJ) :

/* Ajouter un fichier : vérification de l'existence du fichier */
SELECT FICHIER.id, POSITION.nom, POSITION.id_dossier FROM FICHIER, POSITION WHERE FICHIER.id = $id_fichier AND POSITION.id_Fichier = FICHIER.id AND POSITION.id_Version IN (SELECT MAX(id_Version) FROM POSITION WHERE id_Fichier = $id_fichier;
/* Ajouter un fichier : */
INSERT INTO FICHIER VALUES(NULL, $num_version, NULL, NULL, NULL, $source);
INSERT INTO POSITION VALUES($num_fichier, $num_version, $nom, $id_dossier, 'T');
/* Ajouter un dossier : */
INSERT INTO FICHIER VALUES(NULL, $num_version, NULL, NULL, NULL, NULL);
INSERT INTO POSITION VALUES($num_dossier, $num_version, $nom, $id_dossier, 'T');
/* MàJ fichier : */
UPDATE FICHIER SET Version_future_maj = $version WHERE id = $id_fichier;

/* Suppression fichier/dossier : */
UPDATE FICHIER SET Version_suppression = $new_version WHERE id = $id_fichier;
DELETE POSITION WHERE id_Version = $new_version AND id_Fichier = $id_fichier;
UPDATE POSITION SET Etat = 'O' WHERE id_Fichier = $id_fichier AND Etat = 'P';
/* Déplacer/Renommer fichier/dossier : */
INSERT INTO POSITION VALUES ($id_fichier, $new_version, $nom, $id_dossier, 'T');
/* si le fichier a déjà été déplacé, on modifie la position du fichier dans la nouvelle version */
UPDATE POSITION SET nom = $nom, id_dossier = $id_dossier WHERE id_Fichier = $id_fichier AND id_Version = $new_version;

- supprimer une « nouvelle version » non active : si jamais, vous voulez reprendre la version depuis le début ou si vous vous êtes trompé lors de sa création :

/* suppression des positions de la version à supprimer */
DELETE FROM POSITION WHERE id_Version = $id_version;
/* suppression des fichiers créés lors de la version à supprimer */
DELETE FROM FICHIER WHERE Version_creation = $id_version;
/* on modifie certaines informations pour garder une table cohérente */
UPDATE POSITION SET Derniere_position = 'O' WHERE Derniere_position = 'P';
UPDATE FICHIER SET Version_suppression = NULL WHERE Version_suppression = $id_version;
UPDATE FICHIER SET Version_futur_maj = NULL WHERE Version_futur_maj = $id_version;
/* on supprime la version */
DELETE FROM VERSION WHERE id = $id_version;

• sauvegarder une « nouvelle version » sans l'activer : c'est dans ce but que nous avons rajouté Version_futur_maj dans FICHIER ainsi que Etat dans POSITION, ceci permettant de ne pas interférer avec les MàJ des clients qui se feront pendant ce temps-là ;

• modifier la source d'un fichier : il peut arriver qu'on souhaite changer la position d'un fichier dans le serveur :

UPDATE FICHIER SET source =$nouvelle_source WHERE id = $id_fichier;

• activer la « nouvelle version » : maintenant que la version est finie, il faut l'activer pour que les clients puissent se mettre à jour :

/* on met à jour les dates de MàJ. */
UPDATE  FICHIER SET Version_maj = Version_futur_maj, Version_futur_maj = NULL WHERE Version_futur_maj IS NOT NULL;
/* on met à jour les Etats des positions */
UPDATE POSITION SET Derniere_position = 'N' WHERE Derniere_position = 'P';
UPDATE POSITION SET Derniere_position = 'O' WHERE Derniere_position = 'T';
/* on active officiellement la version */
UPDATE VERSION SET Active = 'O' WHERE id = 1;