Version imprimable
Bonjour,
je developpe un logiciel qui enregistre les informations sous un fichier XML.
Je cherche des explications sur comment je dois m'y prendre pour pouvoir faire des backups des fichiers et un système de persitence robuste, par exemple pour prévoir les crach système, et les erreurs que pourrait engendrer le logiciel.
J'imagine qu'il doit y avoir des stratégies de conception (pour ne pas dire pattern).
Merci de m'aiguiller.
Je sais que cela ne répond pas a votre question mais pourquoi ne pas utiliser une base de données.
Si vous etes scotches à implémenter la persistence avec un fichier texte (XML = texte) les principes pourraient être:
- garder les versions précédentes,
- s'assurer que le fichier courant a été complètement écrit (pas interrompu par un crash) en passant par un fichier temporaire qu'on renomme après.
Pour (1), vous pourriez confier cela à un outil comme SVN (mais ce n'est peut être pas utile).
- W
PS: Pas de pattern GOF sur le sujet et les patterns POSA sur la persistance portent plutôt sur les DAO et les DB access layer.
Je suis scotché sur un XML effectivement, mais une DB ne resoud par forcément mon problème.
En faite la structure du XML ou de la DB peut etre bonne (vérifiée), c'est à dire répondre à la spécification de la persistance (la XSD en somme) et pour autant présenter une incohérence métier (non valide). Ca arrive quand on fait des choses un peu générique, dans un soucis d'évolutivité, donc moins de typage. Et en faite le logiciel peut lui aussi fonctionner mais l'information devenir un peu incohérente (terrible hein).
Donc je veux faire un mécanisme simple, et j'imagine ceci:
- j'enregistre dans un fichier temporaire toute modification pour faire un backup si il y a un crash system.
- je garde eb backup le dernière version du fichier, puis des versions sur 1 semaine et un mois (comme les versions history sous SVN).
Je ne veux pas utiliser SVN, car le logiciel est en standalone, à moins qu'il y est une API ou qq chose à embarquer.
Une idée me vient: est ce qu'il ne faut pas plutot conserver les différentielles entre les différentes versions du XML, comme on le ferait avec un pattern memento ?
Certes, mais comment l'incohérence va pouvoir être détectée?Citation:
Envoyé par Alec6
Et si elle est détectée dans N jours comment on récupère cela?
Je n'ai jamais regardé s'il existait une API pour SVN mais pour autant que SVN participe à la solution ce ne devrait pas être un problème.Citation:
Donc je veux faire un mécanisme simple, et j'imagine ceci:
- j'enregistre dans un fichier temporaire toute modification pour faire un backup si il y a un crash system.
- je garde eb backup le dernière version du fichier, puis des versions sur 1 semaine et un mois (comme les versions history sous SVN).
Je ne veux pas utiliser SVN, car le logiciel est en standalone, à moins qu'il y est une API ou qq chose à embarquer.
Ce serait "sympa" mais à part compliquer les choses je ne vois pas ce que cela apporte.Citation:
Une idée me vient: est ce qu'il ne faut pas plutot conserver les différentielles entre les différentes versions du XML, comme on le ferait avec un pattern memento ?
-W
L'incohérence métier ne peut pas toujours etre detectée (ca devrait dans l'absolu). L'incohérence va finir par se révéler par des exceptions occasionnées par des actions utilisateurs.
Normalement le modele de données devrait etre blindé au niveau des contraintes métier, mais on ne peut assurrer 100% de cette protection, et moi je gère des données critiques. Donc je dois vivre en paranoiaque.
Il ne faut pas que l'utilisateur puisse enregistrer son travail puis qu'à la prochaine ouverture du fichier tout plante. C'est ca la grande peur.
Mon système de backup est probabiliste, c'est juste pour limiter la casse.
Pour l'idée d'enregistrer les différentielles l'idée est de réduire le volume de données enregistrées, et donc de pouvoir conserver:
- en t le dernier xml modifier par l'utilisateur
- en t-1 la modification qui a amenée à t
- en t-x-1 idem à t-x
Ainsi l'utilisateur peut remonter l'historique des modifications et choisir une version qui semble ne pas planter.
De quel volume parle-t-on?
- W
le volume de Ko, car normalent je dois conserver toute modification, pour la tracabilité. Je l'envisage pas aujourd'hui.
Donc aujourd'hui faire 3 backup sur 1 semaine puis un mois me semble raisonnable.
Heu puisqu'il s'agit de fichier, j'avais compris qu'il s'agissait d'octets mais cela ne me dit pas combien.
-W
PS: je relis tout ca un peu plus tard, pour l'instant, je bouge
Certes mais quand?Citation:
Envoyé par Alec6
Si on doit attendre que l'utilisateur accède à une donnée incohérente, c'est pas le dernier backup qui va pouvoir y faire grand chose!
Soit les données sont critiques et leur protection doit être assurée, soit on prend des risques et il serait sage d'en faire la balance avec la criticité.Citation:
Normalement le modele de données devrait etre blindé au niveau des contraintes métier, mais on ne peut assurrer 100% de cette protection, et moi je gère des données critiques. Donc je dois vivre en paranoiaque.
Et au plus c'est critique au plus on fait simple!
Il y a d'un côté l'intégrité des données stockées et de l'autre pallier une écriture partielle suite à un crash.Citation:
Il ne faut pas que l'utilisateur puisse enregistrer son travail puis qu'à la prochaine ouverture du fichier tout plante. C'est ca la grande peur.
Mon système de backup est probabiliste, c'est juste pour limiter la casse.
Si vous n'êtes pas capable de vérifier l'intégrité de vos données, c'est même pas la peine de les écrire sur disque.
Compliquer n'est jamais mieux surtout que si ne savez apparament toujours pas détecter les inconsistances. En ayant des copies "complètes" vous pourrez toujours repartir de quelque chose de cohérent alors qu'avec des incréments vous augmenter les risques de véroler l'ensemble de vos informations.Citation:
Pour l'idée d'enregistrer les différentielles l'idée est de réduire le volume de données enregistrées, et donc de pouvoir conserver:
- en t le dernier xml modifier par l'utilisateur
- en t-1 la modification qui a amenée à t
- en t-x-1 idem à t-x
Ainsi l'utilisateur peut remonter l'historique des modifications et choisir une version qui semble ne pas planter.
Le volume (nombre de Mo) peut jouer, mais s'il est important mettez le en base pas dans des fichiers plats!
-W