Discussion :

[noftal]

Bonjour,

Je suis en train de réfléchir aux problématiques de mise à jour automatique de mon appli auprès de l'utilisateur final.
Cette appli interagit avec un fichier de base de données qui est créé chez l'utilisateur à la première utilisation (par recopie d'un fichier de BdD situé dans les ressources de mon projet, contenant toute la structure de la bdd mais vierge de tout enregistrement)
Il faut prévoir le cas où une modification de mon appli s'accompagnerait d'une modification de la structure de la bdD (cas typique tout bête : l'ajout d'un champ dans une table)
Il faut que, à la mise à jour chez l'utilisateur, son fichier de bdD en local soit importé dans la nouvelle structure et que ceci donne lieu à l'implémentation d'un nouveau fichier en lieu en place de son fichier.

Quelle stratégie de programmation proposeriez-vous sachant que le logiciel est bien sur capable de trouver le chemin du fichier utilisateur ?

Comment l'appli peut-elle tester si la structure de la bdd vierge située dans les ressources du projet est bien identique à celle du fichier de bdd de l'utilisateur ?
Si structure identique : rien à faire
Si structure différente : injecter les enregistrements du fichiers utilisateur dans une base vierge et remplacement du fichier utilisateur par cette nouvelle base ==> comment faire ?

[Uranne-jimmy]

Ce ne serait pas plus simple de travailler sur un seul fichier mais dont les autorisations sont unique pour chaque nouvel utilisateur ? (ça doit être possible j'imagine)

Sinon une astuce pourrait être faire en sorte que quand l'utilisateur demande une modification structurale, la modification s'applique directement sur les deux fichiers concerné. La mise a jour se ferait alors en temps on ne plus réel.

[noftal]

Salut,
Je ne comprends pas bien ta réponse à moins que ce soit toi qui n'ait pas compris ma situation.
Mon appli est un gestionnaire de bibliothèque perso.
chaque utilisateur de l'appli crée son contenu.
L'appli ne fournit que l'architecture de la BdD.
C'est pourquoi, chaque utilisateur génère son propre fichier de bdd qui correspond à sa bibliothèque : le fichier vierge (contenant juste l'architecture de la base) est généré à la première utilisation de l'appli.
Lors des utilisations suivantes, l'appli va lire le fichier à l'emplacement que lui aura indiqué l'utilisateur.
Quand je fournis l'appli, je ne fournis pas le contenu de la bibliothèque. J'ai donc un fichier de bdd vierge de tout contenu dans mes ressources.
Au lancement de l'appli celle-ci teste si une base a déjà été générée (en allant lire une clé dans la base de registre de l'utilisateur. Si cette clé n'existe pas c'est que le test est négatif)
Si le test est négatif : création d'une clé dans la base de registre de l'utilisateur indiquant le path de l'emplacement du fichier de bdd et création du fichier de bdd vierge à cet emplacement par recopie du fichier vierge situé dans les ressources de l'appli
si le test est positif: l'appli associe la base existante au fonctionnement de l'appli : lecture des données, écriture pour les ajouts/modifications de l'utilisateur

Le pb est donc lorsque je crée une nouvelle version de mon appli. Si je veux pouvoir modifier l'architecture de ma base (le simple ajour d'un champ constitue à ce titre une modification de structure) à cette occasion, il faut pouvoir faire hériter tous mes utilisateurs de cette évolution en récupérant le contenu qu'ils ont créé avec la version précédente de l'appli.

[Uranne-jimmy]

J'avais en effet mal compris !

Donc il faut en premier lieu un système qui détecte si une mise a jour est disponible, chose a effectuer de préférence dans le constructeur du programme, je pense. Ensuite il faudra faire les modifs sur le fichier du client, si j'ai bien compris.
Là je vois deux solutions : soit la mise a jour s'accompagne d'un texte qui servira de directive pour les changements, soit si il y a mise a jour, le programme énumère les structures de ta bdd, les compare avec celle du client puis opère les changements.

Je suis dans le bon ?

[noftal]

@ Uranne-jimmy

La détection de l'existence d'une mise à jour de l'appli se fait automatiquement, si j'ai bien compris, par chaque licence d'appli (je me place dans le case d'une publication de l'appli sur internet avec la méthode click once).

Cela dit, je parle de ce que je ne connais pas encore car je n'ai encore jamais publié d'appli, mais j'ai lu la doc !

Ensuite, seule ta 2ème solution est envisageable. L'utilisateur n'a pas la main pour changer lui-même la structure de la BdD.

@rv26t

Je crois en effet que ta solution est celle qu'il me faut. Y a-t-il un moyen de donner un Id à une base de donnée sans créer une table spécifique avec juste un champ comportant cet Id ou bien est-ce la seule solution possible ?
Ensuite, cela résout la question du test sur l'évolution. Ensuite ya-t-il une méthode simple pour importer le contenu de la base_old dans la base_new ?

[rv26t]

Je crois en effet que ta solution est celle qu'il me faut. Y a-t-il un moyen de donner un Id à une base de donnée sans créer une table spécifique avec juste un champ comportant cet Id ou bien est-ce la seule solution possible ?

Idées a creuser
1) Tu as ta clé de registre indiquant si la base existe. Que mets tu dedans ? (Il pourrait y avoir le numero de version.)
2) Ce qui peut se faire, dans la BDD on fait une table de paramètres banalisés (qui permet de configurer l'appli). Tu la mets dedans. (ca ne semble pas être ton cas)

[Uranne-jimmy]

Pour ce qui est de ma première solution, j'ai mal exprimé mon idée ^^ les directives dont je parle ce serait des directives lu directement par ton programme, pas par l'utilisateur (en 2013 tout de même !). Ces directives seraient composé de l'ensemble des informations nécessaire à la mise à jour.

Mais rv26t est bien plus compétent que moi

[rv26t]

Bonjour,

Au lancement de l'appli celle-ci teste si une base a déjà été générée (en allant lire une clé dans la base de registre de l'utilisateur. Si cette clé n'existe pas c'est que le test est négatif)
Si le test est négatif : création d'une clé dans la base de registre de l'utilisateur indiquant le path de l'emplacement du fichier de bdd et création du fichier de bdd vierge à cet emplacement par recopie du fichier vierge situé dans les ressources de l'appli
si le test est positif: l'appli associe la base existante au fonctionnement de l'appli : lecture des données, écriture pour les ajouts/modifications de l'utilisateur

Tu donnes un numéro de version à la BDD.
Quand tu fais une modif structurelle tu fais évoluer la version.
Avec tes tests, si la base existe tu vérifies le numéro de version entre celle qui existe et celle que tu veux placer. (s'il est différent => évolution)