Wie implementiert man "getestests geänderte Elemente" mit ADO.NET Data Services?

Question

Sagen wir, ich habe eine Liste von Entitäten (zum Beispiel eine Liste von TODO-Elementen), die mehr als ein Benutzer gleichzeitig ändern, löschen und hinzufügen kann.

Also zu maintane eine synchronisierte Liste zwischen allen Clients, ich möchte jeder Client (AJAX-basierte) nach Änderungen alle xx Sekunden fragen. Da die Liste sehr lang werden kann, möchte ich nicht jedes Mal eine vollständige Anfrage machen, sondern nur nach den geänderten Artikeln fragen (Artikel können aktualisiert, gelöscht oder neu sein).

Ist es mit ADO.NET Data Services möglich? Wenn ja, wie implementiere ich es, wenn ich Entity Framework auf dem Server verwende?

Ich habe überlegt, ASP.NETs Cache zu verwenden, um Änderungselemente zu speichern, wenn eine Änderungsoperation an den Datendienst übergeben wird, und über eine benutzerdefinierte Webmethode, die die letzten Änderungen seit der letzten Anforderung der letzten Clients zurückgibt (Anforderungen können sein verfolgt durch die Clients ASP.NETs-Session-Objekt). Ich habe jedoch keine Ahnung, wie der Änderungsstatus des einzelnen Elements (z. B. gelöscht oder aktualisiert oder eingefügt) in der Ergebnismenge angezeigt wird.

Eine großartige Lösung würde es dem Client auch ermöglichen, Änderungen in vielen Entitäten im selben Roundtrip zum Server anzufordern.

Jede Eingabe wird viel appreaciated.

Mit freundlichen Grüßen, Egil.

Answer 1

Der Weg, der mir in den Sinn kommt, ist die Verwendung einer Generationsnummer für den Tisch. Geben Sie der TODO-Tabelle eine Spalte namens generation und (geistig) eine globale und persistente Generationsnummernvariable. (Wahrscheinlich am besten, dies in eine Tabelle in der DB zu legen).

Jedes Mal, wenn eine Aktualisierung oder Einfügung vorgenommen wird, wird die Generierungsnummer erhöht und in die Generationsnummernspalte für den aktualisierten oder eingefügten Datensatz eingefügt.

Wenn die Datensätze zuerst aus der DB gelesen und auf der Webseite abgelegt werden, wird auch die aktuelle Generationsnummer abgerufen und lokal zwischengespeichert (d. H. In eine JavaScript-Variable eingegeben). Nachfolgende AJAX-gesteuerte Lesevorgänge verwenden eine Where-Klausel, die nur Datensätze mit einer Generierungsnummer filtert, die größer als die lokal zwischengespeicherte Generationsnummer ist. Dies stellt sicher, dass nur neue Aktualisierungen und Löschungen abgerufen werden. Die lokal zwischengespeicherte Generierungsnummer wird dann aktualisiert.

Löschen ist ein bisschen komplizierter. Eine Möglichkeit, dies zu tun, ist Tombstone gelöschte Datensätze für einen begrenzten Zeitraum, sagen wir 21 Minuten. Sie haben eine Bitspalte namens Tombstone und eine Datetime-Spalte. Wenn ein Datensatz gelöscht wird, wird die Generationsnummer der Spalte auf die gleiche Weise wie bei einem Einfügen oder Löschen gesetzt, das Tombstone-Bit wird gesetzt und die Datetime wird mit GetDate() auf die aktuelle Zeit gesetzt. Die AJAX-Anforderung des Clients kann dann Datensätze mit dem gesetzten Tombstone-Flag auswählen und sie aus der Client-seitigen Liste entfernen. Wenn der Client so codiert ist, dass alle 20 Minuten eine vollständige Seitenaktualisierung oder ein Ajaxaufruf, der jeden einzelnen Datensatz erhält, erzwungen wird, kann ein DB-Job jede Minute ausgeführt und die veralteten Datensätze, die älter als 20 sind, bereinigt (dh gelöscht) werden Protokoll.

EDIT: Sie müssen nicht tatsächlich die Generationsnummer beibehalten, können Sie die SQL-Funktion MAX über die Generierungsspalte.