Dynacase » Platform » Core

La solution présentée ne peut pas être retenue car elle ne propose à l'utilisateur lambda aucun moyen de résoudre le problème. C'est bien de l'avertir mais il serait plus utile de le laisser re-paramétrer les répertoires temporaires lors de la restauration.

D'ailleurs, on voit aussi un manque de cohérence pourquoi ces paramètres ne peuvent pas être paramétrés à l'installation alors que le pg_service le peut ? Si on suit la logique de cette anno, on devrait juste dire à l'utilisateur votre pg_service est invalide et remettre une valeur par défaut.

De plus, avec la solution proposée on ne peut plus utiliser le système de sauvegarde pour simplement sauver et restaurer à l'identique un contexte sur la même machine.

De plus, avec la solution proposée on ne peut plus utiliser le système de sauvegarde pour simplement sauver et restaurer à l'identique un contexte sur la même machine.

Pour moi ce n'est pas le même besoin :
- l'archive adresse le besoin de partager un contexte et que sa restauration, sur une machine différente, donne un résultat qui soit fonctionnel en minimisant autant que possible les corrections et reconfigurations manuelles.
- la sauvegarde, par expérience, dépend de l'architecture/infrastructure et l'archive n'est généralement le moyen le plus adéquat ou optimal. La sauvegarde est généralement étudiée et mise ne place afin de répondre à des contrainte de rapidité de la sauvegarde, rapidité de la restauration, contraintes de volumes (e.g. sauvegarde incrémentale de fichiers), ne pas interférer avec le contenu du contexte (ce qui n'est pas le cas de l'archivage qui exécute des scripts de {pre,post}-{archive,restore} qui peuvent modifier le contexte), base de données distante sauvegardée par son propre mécanisme indépendamment de la sauvegarde des fichiers du contexte, etc.