Tu parle de faire du CoW, mais comment u vois que tu n'es pas entrain d'écraser une version ? Il faudrait pouvoir vérifier la version que tu écrase au moment où tu l'écrase et je ne vois pas comment faire ça en garantissant qu'il n'y a pas eu de changement entre la vérification et l'écrasement. Pour le cas de SMIT, il est peut être possible de simplement créer des fichiers d'ajout et faire des passes régulière pour agréger les fichiers d'un bug dans un seul fichier (ou surveiller les nouveaux fichiers via inotify – ça reste du Single writer principle –).
La robustesse consiste à continuer à fonctionner malgré les erreurs et les cas limites. Là on se base sur une précondition de l'utilisation pour pouvoir continuer à fonctionner, c'est pas de la robustesse,
Mmh, je ne vois pas de quoi tu parles.
Pour moi la robutesse ce n'est pas de poser une précondition sur la manière dont on utilise le logiciel mais plutôt l'inverse vérifier que tout fonctionne même quand on l'utilise dans des cas non prévu (quitte à balancer des messages d'erreurs). Ici si on ne prévoit pas ce genre de chose dès que tu as quelques utilisateurs qui font des écritures dans un même bug tu peut avoir le format du fichier qui est pourri, un entrelacement entre les messages, etc.
Ce n'est pas une critique contre SMIT qui répond à un besoin donné j'en suis certain, c'est juste qu'on entends souvent parler de la non utilisation de SGBD dans nos colonnes et que je m'intéresse dans le cas général à comment le mettre en place.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pas mal !
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 2.
Tu parle de faire du CoW, mais comment u vois que tu n'es pas entrain d'écraser une version ? Il faudrait pouvoir vérifier la version que tu écrase au moment où tu l'écrase et je ne vois pas comment faire ça en garantissant qu'il n'y a pas eu de changement entre la vérification et l'écrasement. Pour le cas de SMIT, il est peut être possible de simplement créer des fichiers d'ajout et faire des passes régulière pour agréger les fichiers d'un bug dans un seul fichier (ou surveiller les nouveaux fichiers via inotify – ça reste du Single writer principle –).
Pour moi la robutesse ce n'est pas de poser une précondition sur la manière dont on utilise le logiciel mais plutôt l'inverse vérifier que tout fonctionne même quand on l'utilise dans des cas non prévu (quitte à balancer des messages d'erreurs). Ici si on ne prévoit pas ce genre de chose dès que tu as quelques utilisateurs qui font des écritures dans un même bug tu peut avoir le format du fichier qui est pourri, un entrelacement entre les messages, etc.
Ce n'est pas une critique contre SMIT qui répond à un besoin donné j'en suis certain, c'est juste qu'on entends souvent parler de la non utilisation de SGBD dans nos colonnes et que je m'intéresse dans le cas général à comment le mettre en place.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)