universalID wirklich unique?

Meines Wissens nach nicht.

Die Frage ist vor allem wie du über die Dokumente iterierst, evtl verarbeitest du da ja Dokumente mehrmals

Innerhalb einer DB ist es komplett unmöglich, dass eine UniversalID doppelt vorkommt. Versucht man beispielsweise, ein Dokument zu speichern mit einer UNID, die es bereits gibt, wird automatisch und ungefragt eine neue UNID vergeben.

Würde dieser Prozess nicht funktionieren, würde man die wunderlichsten Erlebnisse bei Replikationen haben - dieses Geschrei wäre in der kompletten Notes-Community zu hören sein.

Es wird also eher an Deinem Algorithmus etwas nicht simmen.

Bernhard

Tut mir leid, wenn taurec und Bernhard widersprechen muss, aber theoretisch ist es sehr wohl möglich, dass 2 Dokumente die selbe UNID haben. Im KB-Artikel 1112556 ("How to generate a UNID (Universal ID) using LotusScript") ist beschrieben, wie eine UNID aufgebaut ist:

Zitat

The UNID is made up of 32 hex digits as follows:
* The first 16 digits are random
* The next 2 digits are based on the time zone where the document is created
* The next 6 digits are based on the GMT date when the document is created
* The last 8 digits are the number of hundredths of seconds that have passed in the day (again) based on the GMT.

Alles anzeigen

Und der letzte Punkt ist der entscheidende: obwohl es sehr unwahrscheinlich ist, dass in der selben Zeitzone, am selben Tag, in der selben 100stel Sekunde ein Dokument abgespeichert wurde, kann es durchaus vorkommen. Vor allem in geclusterten Umgebungen. Weil: wir brauchen uns von den ersten 16 Stellen nicht täuschen lassen: wirklichen Zufall gibt es nicht, sondern nur eine Zahl, die ein wie auch immer gearteter Algorithmus ausspuckt. Und der selbe Algorithmus wird unter identischen Bedingungen immer das selbe Ergebnis liefern. Wird also nun tatsächlich am selben Tag, in der selben Zeitzone, zur exakt der selben Zeit auf 2 Servern in 2 Datenbanken der Mechanismus angestoßen, der den Domino veranlasst, die UNID von 2 von einander unabhängigen Dokumenten zu berechnen, die UNID in die Dokumente zu klatschen und die Dokumente dann zu speichern, werden beide Dokumente die selbe UNID haben.

Wie gesagt: sehr theoretisch und gesehen hab ich sowas auch noch nicht. Aber möglich.

RockWilder

Stimmt schon, aber hast du mal probiert ein Dokument zu erzeugen mit einer UNID, die es bereits gibt ?
Dieses Dokument bekommt dann ganz automatisch eine neue UNID und ich hab bisher noch keinen Fall gesehen, indem das nicht auch bei der Replizierung so war.

D.h. ich generiere auf Server1 und Server2 jeweils ein Dokument mit gleicher UNID.
Server1 repliziert jetzt mit Server2 und schiebt als erstes sein erstelltes Dokument in Server2 DB.
Dabei bekommt es eine neue UNID, weil die UNID auf Server2 schon existiert.
Bei der anschliessenden Replizierung der Änderungen von Server2 nach Server1 bekommt Server1 diese geänderte UNID wieder zurück.

D.h. theoretisch kann es tatsächlich sein, daß auf verschiedenen Repliken einer DB mehrere Dokumente mit gleicher UNID existieren (zwar nur temporär), niemals aber innerhalb der gleichen Replik.
Und darum ging es ja hier

Zitat

D.h. ich generiere auf Server1 und Server2 jeweils ein Dokument mit gleicher UNID.
Server1 repliziert jetzt mit Server2 und schiebt als erstes sein erstelltes Dokument in Server2 DB.
Dabei bekommt es eine neue UNID, weil die UNID auf Server2 schon existiert.
Bei der anschliessenden Replizierung der Änderungen von Server2 nach Server1 bekommt Server1 diese geänderte UNID wieder zurück.

Und da bist du dir sicher? Weil das im Endeffekt den Mechanismus der Replikation aushebeln würde. Der Replikator entscheidet anhand der UNID, dass ein Dokument in DB1 ein Äquivalent in DB2 hat und repliziert diese miteinander.

Dass der Replikator von sich aus entscheidet, welche UNIDs sein dürfen und welche seiner Ansicht nach falsch sind, das halte ich für ein Gerücht. Zumal: deiner Logik nach, hätte ich nach der Replikation in DB1 2 identische Dokumente, die sich dann nur durch die UNID unterscheiden: einmal mein ursprüngliches Dokument und einmal das, das der Replikator eigenmächtig verändert hat. Nee, tut mir leid, aber das kann ich nicht glauben.

Völlig sicher kann ich da natürlich nicht sein, da ich dazu den Quellcode vom Domino kennen müsste, aber
1. passiert genau diese Neuvergabe auch wenn du manuell ein Dokument mit einer UNID anlegen willst, die schon vorhanden ist Und da der Replicator für das Anlegen von neuen Dokumenten in einer Replik auch nur die Standard API Funktionen verwenden wird, dann wird das da genauso passieren
2. kann ich mir nicht vorstellen, daß so ein Fall nicht abgehandelt wird
Da die Änderung innerhlab einer Replizierung ja gemacht wird, wird da wohl etwas zwischengecacht.

Ich hatte den Fall schon mal, daß in einer Datenbank sich die UNID eines Dokumentes zwischen dem Abspeichern und dem neu öffnen geändert hatte.
Es war dabei in einem Feld die UNID gespeichert und die hat eben nicht mehr mit der des Dokumentes übereingestimmt.

Ich kanns zugegebenermaßen auch nicht nachstellen. Zumindest nicht in ein und der selben Datenbank. Da werden scheints tatsächlich irgendwelche Kontrollmechanismen greifen.

Mit 2 Datenbanken allerdings klappt das. Lustige Resultat gibt es, wenn 2 völlig verschiedene Masken für die jeweiligen Dokumente verwendet werden. Wenn die beiden Masken dann noch ein paar Felder haben, die zwar gleich heißen, aber zum einen von unterschiedliche Datentypen sind und dann auch noch die Dokumente in den Items unterschiedliche Werte haben, wirds ganz wild. Wobei es scheinbar keinen Unterschied macht, ob das jüngste Dokument zieht, bzw. das mit der höchsten sequence ID, oder ob die Inhalte gemerged werden sollen. In allen Fällen scheint zu 50% ein Replizierkonflikt erstellt zu werden und in der anderen Hälfte der Fälle es vom Zufall abhängig zu sein, was wohin repliziert wird.

Aber lustig ist es allemal, was da passiert.