Questions & Answers

[ana_oleski]

Hi,

  wir haben folgendes Problem: wir synchronisieren die FirstSpirit Datenbank zu einem Windows Azure SQLServer. Die Synchronisierung geschieht nur in einer Richtung - in den Cloud.

Die Datenbank in dem Cloud wird nur von der Webanwendung - ebenfall im Cloud - benutzt  (FS Integration, FS Search und eine eigene Entwicklung).

Sobald Datensätze über den Redaktionsclient geändert und freigegeben werden, haben wir in den Cloud mehr Datensätze als in der Masterdatenbank.

  Laut der Dokumentation von Windows Azure müssen die Tabellen,  die synchronisiert werden, immer ein Primärschlüssel haben. Der Primärschlüssel  bei den FS Tabellen setzt sich, wenn DBVisualizer nicht lügt, aus 4 Spalten zusammen:

  FS_ID

  FS_RELEASE_TO

  FS_VALID_FROM

  FS_VALID_TO

  Vermutlich synchronisiert der Windows Azure SQL Data Sync so, dass:

  Datensätzen mit gleichen Primären Schlüssel werden geändert.

  Datensätze mit anderen (neuen) Primären Schlüssel werden neu hinzugefügt.

  Wenn wir Datensatz X über FS ändern und freigeben, wird einen neuen Datensatz Y  hinzugefügt und  im ursprünglichen Datensatz  X das Attribute FS_RELEASE_TO geändert.  Wenn jetzt eine Synchronisation vorgenommen wird, erkennt der SQL Data Sync den Datensatz X nicht als schon vorhanden, weil der Primärschlüssel sich geändert hat. Fügt ihn also als neuer Datensatz hinzu.

  Der neue (aktuelle) Datensatz Y wird auch nicht als neue Version des existierenden Datensatzes erkannt, weil der Primärschlüssel hier auch anders ist , wegen geänderten Werte in FS_VALID_FROM und FS_VALID_TO.

  Und schon haben wir 3 Datensätze statt zwei, zwei davon aktuell.

Irgendeine Idee, was man da machen kann? Können wir eine zustäzliche auto-increment Spalte definieren und die als Primätschlüssel definieren? Oder wird FirstSpirit das gar nicht mögen?

Wo ich dabei bin: kann ich das SQL sehen, das FirstSpirit absetzt?

[Peter_Jodeleit]

Datenquellen, die über FirstSpirit angelegt werden, sind "temporal". D.h. bei der Übertragung in eine nicht-temporale Datenbank muss der temporale Aspekt "rausgerechnet" werden. Das kann man z.B. über einen View machen, der nur den "aktuell gültigen Stand" der Datensätze ausliefert. Bei der Frage aber, ob Windows Azure das unterstützt, bin ich überfragt, ich bin in Microsoft-Technologien nicht firm.

Fachlich muss der View die FS_* Spalten bis auf FS_ID ausblenden und eine Einschränkung auf FS_VALID_TO = 9223372036854775807 vornehmen (oder entsprechend auf FS_RELEASE_TO für freigegebene Datensätze). 9223372036854775807 ist der verwendete Wert für "unendlich", ansonsten stehen in den Spalten Zeitstempel oder 0 für "nicht freigegeben".

Wo ich dabei bin: kann ich das SQL sehen, das FirstSpirit absetzt?

In den Logging-Einstellungen den Level für "de.espirit.or" auf "DEBUG" setzen, dann erscheint das SQL im fs-server.log.

[ana_oleski]

Hi,

das Problem ist nicht, dass die FS Tabellen temporal sind, sondern dass der Primärschlüssel eines Datensatzes sich ändert. Und das bringt die Replikation durcheinander.

Die Webandwendung hat schon jetzt die entsprechende where Bedingung, um nur freigegebene Datensätze zu finden. Der Code ist gleich on site und im cloud, die Datenbank auch. Oder soll so sein.  Aber im Cloud findet dieselbe SQL Abfrage 2 Datensätze statt 1.

Wir haben ausprobiert, was passiert, wenn wir eine extra identity Spalte definieren und die als PK nehmen. First Spirit scheint sich nicht daran zu stören und die Replikation funktioniert richtig.

Gibt es irgednein Szenario, wo das Vorhandensein einer zusätzliche PK-Spalte in den Tabellen Ärger machen könnte?

[Peter_Jodeleit]

das Problem ist nicht, dass die FS Tabellen temporal sind, sondern dass der Primärschlüssel eines Datensatzes sich ändert.

Ich habe versucht, die Funktionsweise von temporalen Datenquellen in FirstSpirit zu erläutern. Und da ist der Primärschlüssel eines Datensatzes eben abhängig von der Zeit.

Ich weiß jetzt nicht, wie eure gebaute Lösung funktioniert (bzw. funktionieren kann) - wenn diese aber für euch funktioniert: Umso besser.

Gibt es irgednein Szenario, wo das Vorhandensein einer zusätzliche PK-Spalte in den Tabellen Ärger machen könnte?

Das ist schwer zu beantworten Ich gehe mal davon aus, dass diese Spalte nicht Teil des Datenmodells von FirstSpirit ist. Ausserdem vermute ich, das dies eine auto-increment-Spalte ist. Dann wird sichFirstSpirit wahrscheinlich nicht daran stören. Aber das solltet ihr lieber ausprobieren.

Ich vermute aber, das die Replikation fachlich nicht funktioniert, bzw. du weiterhin das Problem aus deinem Ursprungsposting hast.

[ana_oleski]

Ja, wir haben eine auto-increment Spalte - identity oder so  -  ausserhalb von FS hinzugefügt und seitdem läuft alles rund.

Danke für die Erklärung.