Discussion :

[if_zen]

Bonjour !

Je suis en train de développer une application embarquée en java, qui est sensée se connecter sur Internet, quand elle le peut pour synchroniser ses données.
Le serveur contient la base de donnée de référence, et l'application stocke ses propres données avec hsqldb.
Ca fait un petit moment que je réfléchis à comment rendre la synchronisation la plus fiable possible, mais je peine quelque peu...
Ci-dessous, voici l'état actuel des choses, en gros.

Le serveur contient des données sur un matériel précis. L'utilisateur 1, qui a le droit de modifier ces données, d'en rajouter, etc, après avoir synchronisé une premiere fois, décide de le modifier. Pendant ce temps là, l'utilisateur 2 décide lui aussi de modifier l'objet, alors que l'application administrateur lui, aura par exemple décidé de supprimer cet objet...

En gros mon problème vient à sélectionner l'information qu'il est nécessaire de mettre à jour ou non sur et à partir du serveur. (dans les 2 sens quoi).

Est-ce que ce genre de problème est fréquent et existe-t-il des solutions "connues" ?

Je pensais peut-être à gérer un genre d'historique sur le serveur, et de sélectionner l'information par date, mais je vois pas comment faire. La base a plusieurs tables, est-ce qu'il faut un champ dateDonnée par table ?

je suis un peu perdu surtout... Dc si vous avez des idées je suis preneur, merci :-)

[sinok]

Ca fait un moment que je me tourne la tête sur ce problème de mode connecté déconnecté et je ne trouve pas de solution satisfaisante sans grosses contraintes pour les utilisateurs et peu de doc sur le net.
Une idée serait peut être d'aller demander ça à nos potes du forum SGBD qui en sauront forcément plus sur ceci que des javaistes

[if_zen]

voui c'est pas bete Merci...

En ajoutant un champ dateSQL (qui contient la date + heure de la dernière modif) ça regle une partie du problème, mais maintenant le truc c'est qu'il faut savoir si les enregistrement sont des modifs ou des ajouts, parce que avec des clés primaires en auto incrément, on tombe pas forcément sur les memes enregistrements...

Bon j'vais demander la bas merci

[sinok]

Au pire tu rajoute un booléen pour savoir si c'est un ajout ou une modif

[Grand sorcier]

Regarde le protocole SyncML....

mais c'est peut être un peu trop poussé
si tu as juste besoin d'exporter un base (par exemple au format CSV).

[if_zen]

salut !

J'allais te dire je vois pas le rapport, mais après réflexion ton idée me semble pas mal... Genre quand je fais un insert, je mets à 0 et quand j'update, je mets à 1...

PAr contre reste le probleme suivant :

Table serveur : User
id : 1
nom : Martin
prenom : Alexandre
dateSQL : 2006-05-22 11:52:32
isUpdate : 0

Table Client : User
id : 3
nom : Alexandre
prenom : Martin
dateSQL : 2006-05-22 17:24:45
isUpdate : 1

Admettons que le client veuille mettre à jour l'enregistrement ci-dessus sur le serveur... Comment peut-il savoir qu'il s'agisse de celui-ci ?

Sinon faut que je vire les auto_increment de partout, mais ça va vraiment être tendu pour toutes les tables...

[KiLVaiDeN]

Salut,

Pour gérer ce genre de problèmes, vous pouvez vous inspirer du fonctionnement des outils de contrôle de versions, de type CVS, SVN ou autres SourceSafe, ClearCase etc etc.

Il y a deux modes de fonctionnement notables :

mode Lock-Modify-Unlock
On bloque cet enregistrement, on le modifie, et quand on applique la modification, il est délocké. Ainsi, si deux personnes essaient de modifier un même enregistrement à un instant T, il faut qu'elles attendent que l'enregistrement soit libéré avant de faire la modification. Si ton application peut se connecter à souhait à ta bdd, elle peut donc locker un enregistrement quand c'est nécessaire; et donc les problèmes de synchro seront "résolus"... Ca sera gênant pour l'utilisateur par contre, car il faudra qu'il attende que le fichier soit délocké, et ça peut prendre du temps... Peut-être mettre en place un mecanisme de delockage automatique au bout d'une minute... Je ne sais pas trop...

mode Copy-Modify-Merge
Que vous connaissez surement, chaque personne a une copie du fichier, fait les modif qu'elle veut, et envoie la modif sur le serveur; les modifications "compatibles" entre elles sont intégrées, par contre, quand il y a un conflit, un opérateur doit le régler; l'administrateur par exemple...

Tout ceci implique donc la mise en place d'un historique des actions.. Ca peut être plus ou moins lourd, mais je pense que c'est une étape à laquelle tu aurais dû réfléchir dès le début du projet car c'est un problème qu'il était facile d'identifier dès le départ, et la solution aurait peut-être pû être envisagée en amont, ce qui t'aurait évité tous les problèmes actuels ( sans être agressif ni méchant, je dis ça juste pour info )

A+

[if_zen]

salut !

Merci bien pour toutes ces précisions ! Par contre subversion et CVS je ne connais que pour la gestion des projets en groupe... Mon pb concernait plutot les données contenues dans une base de données, en mode communication (et mise à jour) client-serveur...

Mon projet n'en est qu'a ses débuts, mais il est vrai que je n'ai pas passé assez de temps à analyser la synchronisation...

J'hésite un peu à faire un genre d'historique, et puis dans un sens si un enregistrement n'a pas le meme ID il sera supprimé puis recréé, les références devraients être bonnes si elles le sont côté serveur...

Bon je vais essayer comme ça, on verrra bien de toute façon...