Stratégie de mise à jour d'une base de donnée locale depuis serveur
muqaddar
Administrateur
Salut,
Dans mon application, j'ai une base sqlite.
1) Je souhaite mettre à jour cette base de données depuis un serveur via une synchronisation.
Donc je copie la base dans la sandbox au premier lancement de l'application.
Je peux mettre à jour ma base de données via le serveur et des PULL.
J'aimerais pouvoir mettre à jour le fichier lui-même lors des prochaines releases de l'application également, pour ceux qui n'utilisent pas la synchronisation.
C'est faisable en détectant la version du fichier par rapport à la version de l'application, et donc en forçant la copie pour remplacer le fichier déjà copié.
Le problème, c'est que si j'envoie une nouvelle release, disons 1.1, que l'utilisateur ne la télécharge pas tout de suite, et que si entre temps j'envoie des nouvelles requêtes sur le serveur pour que l'utilisateur puisse faire des nouveaux PULL, le fichier présent dans la release aura moins d'éléments et sera moins récent que le premier fichier mis à jour par la synchro serveur.
Vous allez me dire, ce n'est pas grave, si la synchro est bien faite, ça lui fera re-télécharger les nouveaux éléments plus récents lors d'une prochaine synchro. C'est vrai. Cependant, si sa base de données pointait déjà , via des relations notamment, vers des éléments récents déjà téléchargés, ceux-ci ne seront pas retrouvés (sauf s'il fait de suite une synchronisation), et dans le meilleur des cas, il aurait des champs vierges, dans le pire, une plantade.
Donc, je cherche à trancher, ou à une meilleure suggestion de votre part, entre pouvoir mettre à jour la base via serveur ET via nouvelle release de l'application. Vous allez peut-être me suggérer de rapatrier un numéro de version de la base depuis le serveur pour ne pas avoir à l'écraser si elle est plus récente, mais je n'en veux pas: ma synchro est faite pour pouvoir tourner "dans le désordre", peut-importe quel élément est absorbé avant tel autre, ce qui est bien pratique dans le cas de plantages réseau ou autres... donc je ne veux pas numéroter mes versions de base de données sur le serveur.
2) Et tant que j'y suis, j'étais favorable à laisser les termes de traductions des records de bases de données dans des fichiers .strings (et mettre juste une clé en base), mais je suis coincé pour la synchronisation: celle-ci doit envoyer non seulement les records mais aussi les traductions, donc au moins pour une table, je vais remettre les traductions en base... et pas dans un .strings. C'est souvent un dilemme pour moi de choisir entres ces 2 options, car j'aime bien l'idée de mettre toutes les traductions dans un fichier texte plutôt qu'en base (surtout que l'ajout d'une langue impose de modifier la structure de la base... contrairement au .strings)
Dans mon application, j'ai une base sqlite.
1) Je souhaite mettre à jour cette base de données depuis un serveur via une synchronisation.
Donc je copie la base dans la sandbox au premier lancement de l'application.
Je peux mettre à jour ma base de données via le serveur et des PULL.
J'aimerais pouvoir mettre à jour le fichier lui-même lors des prochaines releases de l'application également, pour ceux qui n'utilisent pas la synchronisation.
C'est faisable en détectant la version du fichier par rapport à la version de l'application, et donc en forçant la copie pour remplacer le fichier déjà copié.
Le problème, c'est que si j'envoie une nouvelle release, disons 1.1, que l'utilisateur ne la télécharge pas tout de suite, et que si entre temps j'envoie des nouvelles requêtes sur le serveur pour que l'utilisateur puisse faire des nouveaux PULL, le fichier présent dans la release aura moins d'éléments et sera moins récent que le premier fichier mis à jour par la synchro serveur.
Vous allez me dire, ce n'est pas grave, si la synchro est bien faite, ça lui fera re-télécharger les nouveaux éléments plus récents lors d'une prochaine synchro. C'est vrai. Cependant, si sa base de données pointait déjà , via des relations notamment, vers des éléments récents déjà téléchargés, ceux-ci ne seront pas retrouvés (sauf s'il fait de suite une synchronisation), et dans le meilleur des cas, il aurait des champs vierges, dans le pire, une plantade.
Donc, je cherche à trancher, ou à une meilleure suggestion de votre part, entre pouvoir mettre à jour la base via serveur ET via nouvelle release de l'application. Vous allez peut-être me suggérer de rapatrier un numéro de version de la base depuis le serveur pour ne pas avoir à l'écraser si elle est plus récente, mais je n'en veux pas: ma synchro est faite pour pouvoir tourner "dans le désordre", peut-importe quel élément est absorbé avant tel autre, ce qui est bien pratique dans le cas de plantages réseau ou autres... donc je ne veux pas numéroter mes versions de base de données sur le serveur.
2) Et tant que j'y suis, j'étais favorable à laisser les termes de traductions des records de bases de données dans des fichiers .strings (et mettre juste une clé en base), mais je suis coincé pour la synchronisation: celle-ci doit envoyer non seulement les records mais aussi les traductions, donc au moins pour une table, je vais remettre les traductions en base... et pas dans un .strings. C'est souvent un dilemme pour moi de choisir entres ces 2 options, car j'aime bien l'idée de mettre toutes les traductions dans un fichier texte plutôt qu'en base (surtout que l'ajout d'une langue impose de modifier la structure de la base... contrairement au .strings)
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Peut-être que je veux le beurre et l'argent du beurre, et le c...l de la crémière.
Bon, toujours faire au plus simple.