Vous n'êtes pas identifié(e).
Dans le cadre d'un développement spécifique, nous recherchons une solution apte à réaliser de la réplication asynchrone symétrique (de type Maitre-Maitre) à la demande. Notre application est sous environement win32. il semble que rubyrep soit le seul produit à répondre à nos besoins.
L'utilisez-vous et si oui, y-a t-il des problèmes de fiabilité ou de lenteur ?
Y-a t-il d'autres solutions pour des applications Client-serveur avec des postes itinérants déconnectés qui doivent pouvoir lire et écrire dans la base et se synchroniser avec le siège ?
Par avance, merci.
Hors ligne
Bucardo me semble plus adapté à ce type de cas. Ce sera de toute façon lent. Toute solution maître/maître est intrinséquement lente.
Guillaume.
Hors ligne
Bucardo ne tourne pas sous Win32 à ma connaissance. Il y a un script PERL qui utilise des spécificités Unix et qui n'a jamais été porté sous windows.
Hors ligne
Ce genre de réplication est loin d'être évidente et sacrément complexe et dangereuse.
Envisagez une autre façon de travailler coté base n'est pas possible ? multi schéma ? certaines tables descendantes alors que d'autres montantes ?...
Hors ligne
Le besoin est pourtant simple : une CRM avec des fiches clients qui peuvent être modifiées par le siège et par les postes déportés, mais qui fonctionnent en mode déconnecté. Au delà de ça, c'est plus de 50 tables concernées, mais je ne vois pas comment tourner les choses autrement.
Je viens de tester RubyRep, il répond aux spécifications. Maintenant, est-il stable ?Pas évident, très peu de retour d'expérience à priori...
Hors ligne
il se passe quoi quand le siege modifie la fiche d'un client et que le commercial sur son poste modifie la meme fiche client ?
C'est une vraie question qui me turlupine
Hors ligne
Il y a une gestion des droits et celui qui a le plus de droit l'emporte, tout en générant un log de conflit pour retrouver ses petits. l'idéal serait de gérer à la colonne près, ce que nous envisageons mais qui est assez lourd à développer et pas forcément possible avec Rubyrep. Mais la première solution (par date de modif et par droit), si.
Hors ligne
ah ok c'est votre crm qui gère les conflits.
Ne connaissant pas du tout rubyrep je ne vais pas pouvoir vous aidez, dommage.
Hors ligne
En fait, c'est une procédure de gestion de conflit écrite en Ruby qui fonctionne avec le gestionnaire de conflit de rubyrep. Les droits et les dates de modifs sont dans la database (triggers pour les dates et droits).
Hors ligne
ok merci du renseignement
Hors ligne
Ce n'est clairement pas un problème simple, ce qui est la raison pour laquelle les solutions style rubyrep et bucardo laissent le problème de gestion des conflits à l'utilisateur
Guillaume.
Hors ligne