Wie Latenz in Meteor Sammlung simulieren, einfügen/aktualisieren/entfernen

Wenn ich Meteor.Methoden anrufe, benutze ich

var wait = function(sim){
  if (!sim) {
    var Future = Npm.require('fibers/future');
    var future = new Future();
    Meteor.setTimeout(function() {
      future['return']();
    }, latency * 1000);
    future.wait();
  }
};

Latenz auf dem Server zu simulieren. Gibt es eine Möglichkeit, Latenz zu simulieren, wenn Sie direkt mit Meteor.collections umgehen?

update:

Ich möchte anrufen

mycollection.insert({whatever:iwant}, function(error, result){   
   ... show that the server collection is updated now ...
});
... show that the server collection is not updated yet ...

Um dieses Verhalten zu testen, möchte ich die Latenz auf der serverside simulieren, wie ich es bereits für Meteor.method-Aufrufe mache.

0
Entschuldigung, ich denke, ich erkläre nicht, was ich richtig machen möchte. hat meinen Beitrag aktualisiert.
hinzugefügt der Autor fastr.de, Quelle
Es wird automatisch für den Client kompensiert . Das ist die Sache mit Meteor - selbst wenn Sie die Latenz für DDP simulieren, werden Sie nichts bemerken, es sei denn, Sie definieren auf dem Client und dem Server verschiedene Zulassen/Verweigern-Regeln. Der Client aktiviert die Sammlungen über minimongo, sodass der Client niemals auf die Antwort des Servers wartet, um eine Aktion auszuführen. Er verwendet lediglich die Antwort des Servers, um die minimongo-DB zu reparieren, wenn sie nicht einverstanden ist.
hinzugefügt der Autor sbking, Quelle
Latenz wird auf dem Client automatisch mit Collection-Methoden wie Einfügen/Aktualisieren/Entfernen simuliert, aber was würde es bedeuten, Latenz auf dem Server zu simulieren ?
hinzugefügt der Autor BenjaminRH, Quelle

1 Antworten

Sie können die Latenz auch mit clientseitigen Methoden simulieren

Clientseitiger Anruf

Meteor.call("something");

Clientseitige 'virtuelle Methode'

Meteor.methods({
    something:function() {
        Collection.insert({this_is_virtual: true});
    }
});

Serverseitige Methode

Meteor.methods({
    something: function() {
        wait();
        Collection.insert({this_is_virtual: false});
    });
});

Die clientseitige Methode erstellt aus Gründen der Latenzkompensation gefälschte Daten mit dem Wert this_is_virtual als true . Sobald die echten Daten eintreffen, wird es sich zu false ändern.

Sie können damit simulierte Daten auf dem Client erstellen. Die gleichen Methoden können auch serverseitig verwendet werden. Sie können this.isSimulation verwenden, um festzustellen, ob es sich um eine virtuelle Methode für die Latenzkompensation handelt.

Clientseitige Sammlungen werden mit dieser "Latenzkompensation" hinzugefügt. Also selbst wenn Sie Latenz simuliert haben, würde es nichts machen .

Dies ist eines der Grundprinzipien von Meteor. Wenn Sie es vermeiden möchten, müssten Sie eine Methode/einen Aufruf wie die obige verwenden, aber ohne einen clientseitigen Simulations-Stub. Aber ich vermute, das wäre es nicht wert, weil die Latenzkompensation eine hilfreiche Funktion ist.

0
hinzugefügt
@Mitar Die _id wird auf dem Client generiert und wartet darauf, dass sie vom Server bestätigt wird. Siehe github.com/meteor/meteor/blob/devel/packages/mongo-livedata/& zwnj; & hellip;
hinzugefügt der Autor Akshat, Quelle
Danke für deine Antwort, aber ich weiß, wie Methoden funktionieren und dass Sammlungen Meteor.Methoden auch intern sind. Ich hoffe, dass mein Update hilft, klarer zu machen, was ich versuche zu tun.
hinzugefügt der Autor fastr.de, Quelle
Wie wird _id s zwischen Client und Server synchronisiert? Wenn ich Collection.insert in der Simulation aufruft, wie kommt es dann, dass Collection.insert den gleichen _id auch auf dem Server generiert?
hinzugefügt der Autor Mitar, Quelle
Dies geschieht jedoch nur, wenn Sie Collection.insert direkt und nicht über die Methode aufrufen. Siehe github.com/meteor/meteor/issues/881
hinzugefügt der Autor Mitar, Quelle