Discussion :

[Jiyuu]

Bonjour à tous,

Je dois créer une application desktop pour deux utilisateurs tout en gérant une base de données comumune. L'idée est de permettre aux utilisateurs d'utiliser l'appli en local tout mettant à jour une BDD stockée sur une serveur ftp.

Ma princiaple interrogation se situe sur la manière de faire. J'entends par là comment s'assurer au moment de la mise à jour que la version téléchargée ou téléversée soit la dernière. QFileInfo permet de connaître la date de modification d'un fichier, mais lors d'un upload ou dowload avec QFtp le traitement de la tache n'est pas forcément immédiat donc a priori problématique.
Une autre solution serait d'identifier le créateur d'une entrée de la BDD et de n'autoriser qu'à celui ci les modifs. Je pourrai aussi pour chaque entrée ajouter une colonne date de maj...
Enfin bref, j'ai plein de possibilité mais laquelle est la bonne ?

Qu'en pensez vous ?

D'avance merci

[tyrtamos]

Bonjour,

Une idée.

Je suppose qu'il s'agit d'une base de donnée relationnelle de type mysql?

Dans le script SQL de construction de la BDD, il est possible de créer une procédure stockée avec un déclencheur (CREATE TRIGGER) qui lance automatiquement une requête SQL lorsqu'on modifie une table (ajout, mise à jour et effacement de données). On pourrait donc avoir une table supplémentaire 'journal' qui enregistre ces modifications fournies par le trigger. A voir ce qu'il est possible d'enregistrer: utilisateur, enregistrement modifié, date et heure de modification. L'avantage de cette solution est qu'il est possible d'interroger à tous moments cette table à distance par simple requête SQL.

Dans tous les cas, il faut organiser les requêtes en transactions, de sorte que ce ne soit pas l'upload de chaque requête qui déclenche la mise à jour physique de la base, mais la requête de fin de transaction. De même, un échec au milieu de la transaction fera que la base restera dans l'état de début de transaction sans tenir compte des 1ères requêtes passées. C'est la seule façon de garantir que la base reste intègre à tous moment.

[Jiyuu]

Merci de ta réponse Tyrtamos,

Petite précision par rapport au fonctionnement que je veux absolument avoir...
En local l'utilisateur doit pouvoir renseigner une BDD (SQlite actuellement mais je réfléchi à utiliser peut être un fichier XML) en local et compléter correctement une autre sur un serveur ftp (comparaison de chaque ligne entre la version locale et distante). En écrivant ces quelques lignes je m'aperçois que la solution est peut être d'ajouter une colonne date de maj.

[wiztricks]

Salut,

Je dois créer une application desktop pour deux utilisateurs tout en gérant une base de données commune. L'idée est de permettre aux utilisateurs d'utiliser l'appli en local tout mettant à jour une BDD stockée sur une serveur ftp.

Il serait sage de clarifier les unités d'informations que vous voulez partager: FTP c'est plutôt des fichiers, une BDD ce sont des enregistrements dans des tables, NFS c'est encore autre chose.

Si c'est un gros fichier, FTP vous demandera de faire une copie locale avoir de faire une comparaison avec des éventuels soucis de cohérence et d'intégrité si des mises à jour du fichier doivent être faites "en même temps".
=> Comment seront détectés et gérés ces conflits?

En local l'utilisateur doit pouvoir renseigner une BDD (SQlite actuellement mais je réfléchi à utiliser peut être un fichier XML) en local et compléter correctement une autre sur un serveur ftp (comparaison de chaque ligne entre la version locale et distante)

Si une mise à jour du local doit être propagée "à distance", c'est en gros un système de réplication.

D'un autre côté si vous devez garantir que la zone partagée est "à jour" ainsi que les copies "locales", pourquoi ne pas installer un serveur de base de donnée en "central" - et oublier les copies "locales" ?

Une autre option serait d'utiliser des copies locales pour permettre un travail "offline"... Les mises à jour n'étant propagées que lorsque l'utilisateur pourra se connecter au "central" - avec une gestion des conflits éventuels.

Que voulez vous faire exactement?

- W
PS: ce n'est ni un sujet Python ni un sujet Qt.

[Jiyuu]

Merci pour cette réponse.

Pour clarifier j'ai une base de données mybdd.db sur mon PC où je stocke des enregistrements. Un autre utilisateur a lui aussi cette même base sur son PC. Afin que chaque utilisateur puisse visionner le travaille de l'autre, voire apporter des modifs je souhaite stocker ce fichier mybdd.db sur un serveur ftp. A chaque ouverture du programme et sous condition d'avoir accès au serveur, un download suivi d'une maj sont faits. A la fermeture c'est un upload et une maj qui sont lancés (en gros c'est ce fonctionnement que je souhaite avoir).

Le but est de permettre à chaque utilisateur de travailler offline et de faire des maj dès que possible.

Voilà dans les grandes lignes.

Pour le mauvais placement du sujet, je précise que l'appli est en PyQt et que j'espère trouver une solution intelligente en PyQt. Ceci expliquant cela.

[wiztricks]

Salut,

En écrivant ces quelques lignes je m'aperçois que la solution est peut être d'ajouter une colonne date de maj.

Maybe.

En fait, il faut retravailler Create/Update/Delete pour que çà fonctionne dans le contexte - comment faire pour savoir "a été détruit" => l'idée du journal proposé par Tyrtamos est à priori incontournable.

On pose enregistrements => schema => clés/valeurs et des relations.
Clés/valeurs et relations ne présentent pas du tout le même niveau de difficultés: restons sur clés/valeurs pour faire simple. Et appelons clés/valeurs: "state".

Première difficulté "create".
A et B créent un enregistrement nécessairement différents dans leur base locale. On pourra leur associer un UUID comme clé pour faire la différence, ce qui nous arrange car la durée de vie d'un UUID est à priori "très grande".
=> enregistrement = UUID, state
Dans le journal, nous aurons les entrées:
(e1, UUID-1, state-1) soumise par A,
(e2, UUID-2, state-2) soumise par B,

next: mise à jour des bases locales.
Le dernier état reçu par A et B est (e0, ...), ils voient donc e1 et e2 et récupèrent en partie ce qu'ils ont déjà.
Le dernier état reçu par A et B sera e2.

Deuxième difficulté "update".
A et B modifient UUID-1
(e3, UUID-1, state-1.1) est soumis par A
(e4, UUID-1, state-1.1) est soumis par B => il faut détecter que e4 n'est pas le successeur d'e3, demander à B de faire sa mise à jour suivant e3 et non plus e2 local.
note: Si A et B font beaucoup de modifications sur les mêmes UUID, et la possibilité de travailler "offline" est ouverte à ce propos, ça risque de ne pas être "user friendly" très longtemps.

3ème difficulté "delete".
A détruit UUID-1 alors que B continue de lui appliquer des mises à jour. Détection comme pour les updates et si A gagne, il y aura création de
(e5, UUID-1, None?) hum: (e5, UUID-1, 'd', state-1.1) est peut être "mieux".

Arbitrages.
Journal et enregistrements mélangés ou construction de "tables" séparées?
Les tables séparées donnent deux schéma:
journal: (ex, states) => states: (UUID, op, state), avec op dans c, u, d

Question sioux: est-ce qu'UUID est la clé primaire de nos enregistrements? Dans ce cas, 1 x UUID = 1 x state.. mais c'est peut être pas si pratique pour retrouver l'état d'il y a 2/3 jours...
Une autre question est côté "métier"/"application": est-ce qu'on peut passer de l'état 0 à 10 sans passer par les mises à jour intermédiaires?

Nombre d'entrées dans les log à définir mais il faut bien 'purger' de temps en temps...

4ème difficulté: UUID.
Techniquement c'est "cool" côté unicité mais suivant "business"/application, vous n'avez peut être pas envie d'entrer plusieurs fois la même personne, la même commande: autre conflit à gérer sur un sous ensemble des clés/valeurs qu'on a caché dans le 'state'.

5ème difficulté: e0 etc...
La question est "comment ce truc est construit": on veut une chose monotone croissante qui permette de trouver les mises à jour effectués depuis la dernière synchronisation.
=> se baser sur le temps du serveur de base de donnée et oui, c'est une chose qui est dans le journal et donc sous sa férule.

6ème difficulté: le schéma change/la maintenance du truc.
Il faudra mettre à jour 3 bases de données. Pas grave, mais il faut y penser.

Grosses difficultés: les relations.
Où comment généraliser la mécanique avec différentes relations.
Le soucis n'est pas tellement côté "interne" à la BDD mais plutôt dans la chronologie des échanges (un seul journal, pleins de tables fonctionne mais c'est pas forcément ce qu'on veut) et les embarras dans la gestion des conflits.

Beaucoup de code, beaucoup de compromis à trouver - en fait, excepté pour les relations, les soucis résultent de la nature "multi-maître" du truc.

Autres solutions.
Bon d'accord, on jette le SGDB et on passe par des documents XML... Mais ces outils intègrent une gestion des conflits.

- un CMS genre 'mercurial'
- un truc genre CouchDB pourrait aussi faire l'affaire, c'est en Erlang mais ca cause bien avec Python.

=> il faut quand même contextualiser Create/Update/Delete et il n'est pas exclu d'avoir besoin du support d'un SGDB 'local' pour indexer tout çà.
ça a le mérite de correspondre a vos use cases.

Bon courage,
- W