Inconsistent behavior of compare_entities in apiutils
I created a MR !44 (merged) with a failing test and some notes.
The current behavior of compare_entities is a bit inconsistent and also partly inconvenient:
- Comparing two Properties directly seems to be different from a comparison of two Records in the result dictionary.
- A set value of two properties compared directly is not taken into account.
- The result dictionary is difficult to interpret.
Refactoring should be considered, but it is important to maintain backward compatibility.
Should be maybe part of a discussion in a smaller working group.
DoD
- Discussed equality of entities
Discussion - Entities Vergleichen
Use Case 1 - Update beim Crawler, Model-Yaml
Beim Crawler geht es darum, einen Ist-Zustand einer (bereits im Server gespeicherten) Entity mit dem Soll-Zustand (der vom Crawler lokal generiert wurde) zu vergleichen und die nötigen Updates daraus zu berechnen, sodass ggf. nicht vom Crawler verantwortete Changes nicht überschrieben werden.
Use Case 2 - Duplikate in einer CaosDB Instanz finden.
Duplikate sind zwei Entities (mit unterschiedlichen IDs) die aber besser durch einen einzigen Eintrag ersetzt werden sollten (Beispiel, zwei Person Records mit derselben Emailadresse).
Use Case 3 - Equivalente in zwei unterschiedlichen CaosDB Instanzen finden.
Equivalente Entities in zwei unterschiedlichen Instanzen sind Entities, die bei einem Merge der Daten der beiden Instanzen durch nur eine Entity repräsentiert werden sollten (Beispiel, zwei Person Records mit derselben Emailadresse)
Use Case 4 - Identifiables
Identifiables sind quasi unique keys, die eine Kombi aus Properties und Parents sein können und dazu dienen eine Entity eindeutig zu identifizieren ohne Verwendung der ID (z.B. ist eine Person eindeutig durch Vorname, Nachname identifiziert, ggf. plus Emailadresse oder Geburtsdatum).
Entityeigenschaften, die zur Beurteilung von Gleichheit oder zur Diffberechnung relevant sind.
| Eigenschaft | Anmerkung |
|---|---|
| id | Gibt Identität an - für Gleichheit irrelevant |
| name | |
| description | Soll ein menschenlesbarer Hinweis zur Verwendung/Definition von etwas sein. Ein Typo sollte keinen Unterschied machen für die Duplikatesuche oder Equivalenz. Beim Update-Diff ist dies aber relevant. |
| parents | Ist ein Set (daher auf tiefe Set-Gleichheit zu testen) |
| parent.id | Identität, sollte daher für Gleichheit nicht ausschlaggebend sein. |
| parent.name | |
| parent.description | Soll ein menschenlesbarer Hinweis zur Verwendung/Definition von etwas sein. Ist ohne hin eine Eigenschaft der Parent Entity. |
| properties | Ist eine List, daher sollte auf tiefe Listen-Gleichheit getestet werden. Es gibt allerdings evtl. Bedarf auf "nur" Set-Gleichheit zu testen. |
| property.name | |
| property.id | Identität |
| property.unit | String-Gleichheit |
| property.value | String-Gleichheit |
| property.data_type | |
| property.importance | |
| version | Wahrscheinlich niemals relevant |
| unit | String-Gleichheit |
| role | |
| value | String-Gleichheit |
| data_type | |
| state | wie property |
| path | Ist Problematisch: Es gibt den Fall "Gleich, aber woanders gespeichert" |
| size, checksum | Zum Duplikate-finden sehr gut geeignet |
Hash
Eine Hashfunktion wäre gut. Entity-Eigenschaften die für die Gleichheit relevant sind, sind auch hier relevant, zumal aus SindGleich(Entity1, Entity2) auch Hash(Entity1) == Hash(Entity2) folgen sollte.