1-more-thing - Mise à jour des données

> Blog

Mise à jour des données

Discussion sur la méthode

Fabrice Nordmann | 13 juin 2010

Suite à la passionnante session de Vincenzo Menanno (FM Nexus) lors de la FM Conférence 2010 à Paris, qui traitait des différentes stratégies de mise à jour de solutions, 1-more-thing a décidé d’emboîter le pas et de lever le voile sa méthode.

1 2

En effet, j’ai été frappé des ressemblances entre notre méthode et celle de Vincenzo, et les petites différences me font penser qu’échanger sur ce thème provoquera des réactions constructives, des ajustements nécessaires. Cet article se veut donc une proposition, et nous espérons apprendre aussi des réactions que vous ne manquerez pas de laisser ci-dessous.

Tout d’abord, ciblons le cas de figure qui fait l’objet de cet article.

La méthode exposée ci-après concerne les grosses mises à jour, et non les petits développements ponctuels, que l’on pourra faire directement sur le serveur, pendant que les utilisateurs travaillent (développement live) ou pendant les heures de fermetures, voire en reproduisant sur la version servie les modifications apportées sur une version de développement (développement offline).

Dans ce cas de grosses mises à jour, nous avons une version de développement qui a été modifiée, et le but est d’importer les données depuis la version précédente. La version de développement est donc destinée à être installée sur le serveur après le processus de migration.

Précisons également que comme Vincenzo Menanno, nous ne sommes pas convaincus par l’approche séparation données/interface, sauf dans certains cas bien précis. Aussi, nous partons du principe qu’il n’y a pas de différence majeure entre l’approche "en séparation" et l’approche classique, sachant qu’il est rare qu’un changement d’interface n’induise aucun changement dans la structure des données. Nous ne préciserons donc pas ci-après les différences qui peuvent théoriquement exister entre les deux approches.

Etapes préliminaires

Avant tout, il va de soi que le transfert massif de données sera beaucoup plus efficace sur un poste client (local) qu’à travers le réseau. Nous devons donc arrêter le serveur (du moins la solution concernée), et en faire une copie sur le poste local.

Pour éviter toute confusion, nous plaçons ce fichier dans un dossier "Old", situé au même niveau que la version de développement.

Nous avons donc une arborescence du type :

Solution.fp7 (destination)
Old
- Solution.fp7 (source)

Mais ceci est en fait un peu trop simple. Lors du développement de la nouvelle version, nous avons peut-être eu besoin de créer des données dont nous aurons besoin, notamment dans les tables de référence (images, libellés, messages, code postaux ou pays…). Ces données ne figurent pas dans la source des données, mais dans la destination.

Or, comme nous le verrons ci-après, une des premières choses à réaliser est de vider le fichier de destination de ses données. En fonction du volume de données, on pourra choisir de supprimer ces données ou de faire un clone du fichier de destination (beaucoup plus rapide si le fichier contient beaucoup de données, FileMaker étant extrêmement lent à cet exercice)

Dans deuxième cas, nous créons un clone du fichier de destination dans un dossier Reference. L’arborescence est donc :

Solution.fp7 (destination)
Old
- Solution.fp7 (source pour les données)
Reference
- Solution.fp7 (source pour les références)

Alternativement, on aura pu développer la solution avec un fichier spécifique pour les tables de référence, ce qui simplifie cette étape, mais pose des problèmes de gestion des comptes, comme toute solution multi-fichiers.

Le renommage des rubriques

Comme nous le verrons plus loin, la migration des données se fera pas un import basé sur les noms concordants des rubriques. Il est donc nécessaire de s’assurer que les rubriques n’ont pas changé de nom entre les deux versions.

Pour cela, nous utilisons l’utilitaire FMDiff, qui permet en quelques minutes de comparer deux versions du fichier fp7. Notons que nous utilisons par ailleurs beaucoup Inspector ou BaseElements, mais ces outils d’analyse demandent un import du Rapport de Structure de Base de Données en XML, ce qui prend pas mal de temps et qui est ici inutile : seuls les renommages nous intéressent. Si vous devez investir dans un outil et un seul, il va néanmoins de soi que ces outils d’analyse vont plus loin que FMDiff.

Une fois ce rapport produit, nous reproduisons scrupuleusement les renommages dans le fichier source.

Pour plus de sécurité, nous comparons ensuite le fichier source modifié au fichier de destination (on n’est jamais à l’abri d’une faute de frappe)

1 2

Haut de la page

(7) Commentaire(s)

Pablo :
13 juin 2010 08:38

Runtime

Merci pour cet article très intéressant.

J’aimerais prolonger la discussion par une question. Qu’est-ce qui, selon vous, reste applicable dans la mise-a-jour d’applications runtime distribuees ? C’est a dire quand le développeur n’a pas accès aux fichiers sources mais doit faire parvenir a ses clients une nouvelle version que les clients doivent être capable de mettre en place tout seuls (donc en 2-3 clics maxi).
Fabrice Nordmann :
13 juin 2010 10:34

Re : Runtime

Bonjour,

il n’y a en fait aucune différence, si ce n’est qu’on pourra proposer une interface simple pour réaliser la première opération, à savoir placer le fichier dans un endroit précis.

L’autre chose, bien sûr, c’est qu’il faut avoir prévu le coup dès le départ, et les scripts qui s’exécutent côté "source" doivent être distribués dans la première version du Runtime.

Par contre, il n’existe pas de solution pour les listes de valeurs et comptes utilisateurs. Pour les listes, il suffit de ne pas les utiliser (on préférera les listes basées sur la base de données), et pour les comptes, ma foi, il n’est pas fréquent que des Runtimes nécessitent plusieurs comptes.

Ce qui est dommage somme toute, c’est que FileMaker pourrait très bien nous proposer tout cela (sauf le renommage) en une seule action.
Pascal 34 :
14 juin 2010 18:25
Bonjour

Tout d’abord merci beaucoup, ce genre de process est rarement développé.

Quelques remarques :
- le passage en boucle d’un modèle à l’autre n’est valable qui si il n’y a qu’un modèle par table donc prudence. En ce qui me concerne je crée un table modèles qui me liste les modèles. Et Un seul a un élément de nom distinctif pour réaliser les imports.
- D’autre part Les ID ou skp, attention ils servent souvent de lien, un cas est limite. Si on a un lien basé sur un ID, que l’enregistrement principal est supprimé et qu’il y a un possibilité de reversibilité de la suppression. l’ID max peut se trouver dans l’enregistrement lié, donc prudence aussi.
- En cas d’erreur pendant la mise à jour, attention votre fichier nouveau peut comporter déjà un certain nombre de données, donc en début de script un nettoyage est une opération indispensable.
- Je crois que le plus simple pour l’import, est de passer le chemin de fichier ancien dans les paramètres de script.
Pascal 34
Fabrice Nordmann :
14 juin 2010 20:40
Re : Bonjour

Merci pour votre message.
1. je ne comprends pas le problème. Les boucles sont ici utilisées dans des phases qui n’altèrent pas les données. Il n’y a donc à mon avis pas de risque.
2. je ne comprends pas bien votre point : les IDs sont importés sans exécuter les auto-entrées, sinon on court à la catastrophe . Voulez-vous bien éclaircir ?
3. non, dans cette méthode, le fichier de destination est bien vide de données au départ (soit par création d’un clone, soit par effacement préalable à l’importation)
4. on peut passer le chemin via un paramètre, pourquoi pas ? mais on induit une dépendance. Dans quel cas y voyez-vous un avantage ?
Merci !
Laurent (lem) :
22 juillet 2010 09:31

Bon article !

Hello,

très bonne initiative d’aborder ce sujet, qui peut souvent faire un peu "peur"... (va-t-on penser à tout ? Y a-t-il des points particuliers à surveiller ?)

Et c’est en effet un bon prolongement "concret" de la session de Vincenzo.

Merci !
Philippe D :
11 août 2010 17:37

Bravo !

Merci pour cet article.

J’en étais arrivé a une construction à peu près similaire sauf que je ne fais pas de boucle car j’ai plus d’un modèle par table, je nomme en dur un modèle je vide la table et j’importe ( après avoir fait une sauvegarde bien sur).

Sinon toujours vérifier sur la mise à jour après l’avoir testé que " selon nom concordant" ne s’est pas transformé en "ordre précèdent" ce que Filemaker se permet parfois de faire sans nous demander notre avis.

Philippe
:
11 août 2010 19:01

Boucles

Bonjour, et merci pour ce commentaire.

Pour les boucles, il n’y a pas de problème puisque l’on vérifie a chaque fois qu’il n’y a pas d’enregistrements : on n’importera donc qu’une fois par table.

Pour ce qui concerne le bug des options d’importation de FileMaker, il se produit quand on change la table de destination (ce qui est fréquent dans ce genre de script où on duplique l’action avant de la configurer).

FileMaker affiche alors les options (ajout/mise a jour et noms concordants/ordre précédent...) correctes, mais en fait elles ont été reinitialisees. Il faut donc les ré-préciser avant de valider. Pour plus de sûreté on refermera l’action de script, la reouvrira et la configurera.