Meteor GroundDB-Granularität für die Offline-/Online-Synchronisierung

Question

Nehmen wir an, dass zwei Benutzer im Offline-Modus Änderungen an demselben Dokument vornehmen, jedoch in verschiedenen Abschnitten des Dokuments. Wenn Benutzer 2 nach Benutzer 1 wieder online ist, werden die von Benutzer 1 vorgenommenen Änderungen verloren gehen?

In meiner Datenbank enthält jede Zeile ein JS-Objekt und eine Eigenschaft dieses Objekts ist ein Array. Dieses Array ist an eine Reihe von Kontrollkästchen auf der Schnittstelle gebunden. Was ich möchte, ist, dass, wenn zwei Benutzer Änderungen an diesen Kontrollkästchen vornehmen, die letzte Änderung für jedes Kontrollkästchen einzeln beibehalten wird, basierend auf der Zeit, zu der die Änderung vorgenommen wurde, und nicht auf der Zeit, als die Synchronisierung stattfand. Ist GroundDB das geeignete Werkzeug, um dies zu erreichen? Gibt es eine Möglichkeit, einen Event-Handler hinzuzufügen, in dem ich eine Logik hinzufügen kann, die ausgelöst würde, wenn eine Synchronisierung stattfindet, und die sich um die Zusammenführung kümmern würde?

Answer 1

Die kurze Antwort ist "Ja". Keine der Boden-DB-Versionen haben Konfliktlösung, da die Logik abhängig von dem Verhalten der Konfliktlösung z. wenn Sie den Benutzer automatisieren oder einbeziehen wollen.

Die alte Ground DB verließ sich einfach auf Meteor's Konfliktlösung (die neuesten Daten zum Server gewinnt) Ich schätze, dass Sie einige Probleme damit sehen können, je nachdem, wann welcher Client online geht.

Ground db II hat keine Methode resume es ist mehr oder weniger nur eine Möglichkeit, Daten offline zu cachen. Es beobachtet eine beobachtbare Quelle.

Ich denke, Sie könnten eine Middleware Beobachter für GDB II erstellen - eine, die die lokalen Daten vor der Aktualisierung überprüft und den Client aktualisiert oder/und den Server aufruft, um die Serverdaten zu aktualisieren. Auf diese Weise haben Sie eine Möglichkeit, mit Konflikten umzugehen.

Ich denke daran zu erinnern, einige Code schreiben, die "deletedAt"/"updatedAt" für einige Arten der Konfliktbehandlung unterstützt, aber wieder sollte ein Konflikt-Handler in den meisten Fällen benutzerdefinierte sein. (Öffnen der Tür für wiederverwendbare Konflikthandler könnte nützlich sein)

Vor allem zu wissen, wenn Daten entfernt werden, kann schwierig sein, wenn Sie nicht "weich" löschen über etwas wie eine "deletedAt" -Entität.

Answer 2

Der "rc" Zweig derzeit grounddb-Caching-2016-Version "2.0.0-rc.4",

Ich dachte an so etwas wie: (etwas dagegen, es wird nicht geprüft, geschrieben direkt in SO)

// Create the grounded collection 
foo = new Ground.Collection('test'); 

// Make it observe a source (it's aware of createdAt/updatedAt and 
// removedAt entities) 
foo.observeSource(bar.find()); 

bar.find() gibt einen Cursor mit einer Funktion observe unsere Middleware sollte das gleiche tun. Lassen Sie uns einen createMiddleWare Helfer dafür erstellen:

function createMiddleWare(source, middleware) { 
    const cursor = (typeof (source||{}).observe === 'function') ? source : source.find(); 
    return { 
    observe: function(observerHandle) { 
     const sourceObserverHandle = cursor.observe({ 
     added: doc => { 
      middleware.added.call(observerHandle, doc); 
     }, 
     updated: (doc, oldDoc) => { 
      middleware.updated.call(observerHandle, doc, oldDoc); 
     }, 
     removed: doc => { 
      middleware.removed.call(observerHandle, doc); 
     }, 
     }); 
     // Return stop handle 
     return sourceObserverHandle; 
    } 
    }; 
} 

Verbrauch:

foo = new Ground.Collection('test'); 

foo.observeSource(createMiddleware(bar.find(), { 
    added: function(doc) { 
    // just pass it through 
    this.added(doc); 
    }, 
    updated: function(doc, oldDoc) { 
    const fooDoc = foo.findOne(doc._id); 

    // Example of a simple conflict handler: 
    if (fooDoc && doc.updatedAt < fooDoc.updatedAt) { 
     // Seems like the foo doc is newer? lets update the server... 
     // (we'll just use the regular bar, since thats the meteor 
     // collection and foo is the grounded data 
     bar.update(doc._id, fooDoc); 
    } else { 
     // pass through 
     this.updated(doc, oldDoc); 
    } 
    }, 
    removed: function(doc) { 
    // again just pass through for now 
    this.removed(doc); 
    } 
}));