Feature #25

XML-Datenimport von OC.de im Entwicklersystem

Added by following about 6 years ago. Updated over 1 year ago.

Status:offen% Done:

0%

Priority name:2 mittel
Assignee:-
Target version:Version 3.2.0
Ticket Referenz: Kategorien:import

Related issues

Related to OC Entwicklung - Orga #9: neues Entwicklersystem einrichten erledigt
Related to OC Entwicklung - Change #243: XML-Client-Reimport verwirft abhängige lokale Daten verworfen
Blocked by OC Entwicklung - Feature #1115: XML-Interface aktualisieren neu

History

#1 Updated by following about 6 years ago

  • Subject changed from XML-Datenimport von OC.de im neuen Entwicklersystem to XML-Datenimport von OC.de im Entwicklersystem
  • Assignee set to Sampiero
  • Estimated time deleted (30.00)

#2 Updated by following about 6 years ago

  • Kategorien set to import

#3 Updated by Sampiero about 6 years ago

  • Status changed from offen to in Arbeit 20%
  • % Done changed from 0 to 10

#4 Updated by Sampiero about 6 years ago

  • % Done changed from 10 to 50

#5 Updated by Sampiero about 6 years ago

  • % Done changed from 50 to 80

#6 Updated by following almost 6 years ago

/htdocs/util-local wurde nach /local verschoben; den neuen XML-Client dann bitte auch dorthin. Wie ist eigentlich der Stand?

#7 Updated by Sampiero almost 6 years ago

Bin fast fertig, kann meine Zeit aber gerade nicht dafür verwenden :)

#8 Updated by following almost 6 years ago

Was ist denn aus deiner Sicht noch offen?

Was mir bislang aufgefallen ist:

  • ignore-Einträge zentral in /.gitignore ablegen
  • tmpdir-Verzeichnis ggf. automatisch erzeugen, wie das archivedir
  • Die neue Version am besten gleich auf der lib2 aufsetzen, d.h. lib2/cli.inc.php statt lib/clicompatbase.inc.php. Die Änderungen dürften vor allem (nur?) die Namen von Konfigurationsvariablen betreffen.
  • Korrektur Wegpunkt-Typen: type = 1, subtype = $wpt['type']
  • Beim Überschreiben vorhandener Cachedatensätze müssen nicht mehr vorhandene Attribute und Wegpunkte gelöscht werden. D.h. am besten die alten Attribute und Wegpunkte eines Caches vor dem Einfügen der neuen löschen.
  • Import der Empfehlungen fehlt
  • resetDB() ist sehr lückenhaft; jede Menge Daten in "abhängigen Tabellen" bleiben stehen, ebeso heruntergeladene Bilder.
    • Am geschicktesten fände ich, im XML-Client nur die User und Removed-Objects zu löschen und alles weitere über Before-Delete-Trigger anzustoßen. Das stellt die Datenkonsistenz sicher und ermöglicht auch selektives Löschen z.B. per Node (s.u.). Dazu alle Tabellen durchgehen und in alle betroffenen Delete-Trigger einbauen, z.B. bei cache_ignore in cacheBeforeDelete und userBeforeDelete.
      • Nach dem Löschen aus der Datenbank alle nicht mehr referenzierten Bilddateien löschen (aus images/uploads, ./thumbs, ./deleted). Das kann auch als manuelle Aufräumfunktion in dbmaintain.php.
    • Wie setzt man die OKAPI sauber zurück (falls installiert)? Das clog muss anschließend neu aufgebaut werden. Sinnvollerweise kommt das als Funktion in die OKAPI-"Facade". (Achtung, OKAPI-Bug: Beim Aufruf via Kommandozeile funktioniert das Exception Handling nicht.)
    • Gespeicherte Suchen werden als BLOB abgelegt und können User-IDs enthalten. Braucht eine Sonderbehandlung.

Der XML-Client war bisher so ausgelegt, dass Daten verschiedener Nodes in einer Datenbank existieren können. Man kann z.B. lokale User, Caches und Logs anlegen und daneben auch die Daten von opencaching.de importieren.

Die neue Version erlaubt das nicht mehr, da neben den UUIDs auch die IDs importiert werden. Beim Entwicklersystem wäre das zu verschmerzen - wer Daten von OC.de importieren will muss halt vorher lokal alles plattmachen; Updaten wäre nicht möglich. Ich fände es trotzdem schade, wenn wir uns diese Möglichkeit verbauen. Es macht wenig Zusatzaufwand, wenn resetDB() wie oben beschrieben umgebaut ist:

  • IDs nicht mitimportieren, sondern per Autoincrement erzeugen lassen
  • In der Konfiguration die Node-ID festlegen, von der importiert wird (zunächst mal nur eine; für mehrere bräuchte es einige Erweiterungen z.B. auch beim Update-Datum in der Sysconfig). Diese muss von der ID des lokalen Systems abweichen ($opt['logic']['node']['id']).
    • Wenn Daten mit einer anderen Node-ID als der konfigurierten reinkommen, den Import abbrechen. Dito wenn Wegpunktkürzel reinkommen, die mit der lokalen Konfiguration kollidieren ($opt['logic']['waypoint_pool']['prefix']).
      • Entwicklersystem-Config wieder auf anderes Wegpunktkürzel als 'OC' einstellen, ich hatte das ungeschickterweise geändert. Braucht eine Aufräumfunktion per Datenbankversionierung für cache_waypoint_pool und für caches.wp_oc.
  • resetDB() löscht nur die Daten dieser einen Node-ID.

Zum kompletten Zurücksetzen der Datenbank könnte man eine zusätzliche Funktion bereitstellen: "select distinct node from user", und dann für alle Nodes resetDB() aufrufen. OKAPI-Reset nur einmal für alles.

Es gibt noch das grundsätzliche Problem, dass beim Komplett-Reimport abhängige lokalen Daten verloren gehen, z.B. Beobachtungslisten, persönliche Notizen zu Caches und Cachemeldungen. Solange es nur für die Entwicklung verwendet wird ist das zu verschmerzen => ich mache dafür ein getrenntes Ticket auf.

Getestet habe ich noch nicht, und ein Review von maintain.php / @XMLSYNC steht noch aus.

#9 Updated by following almost 6 years ago

following schrieb:

  • IDs nicht mitimportieren, sondern per Autoincrement erzeugen lassen

Und in den abhängigen Tabellen dann die IDs der referenzierten Objekte wieder per UUID ermitteln, so wie in der alten Version des XML-Clients.

Für den Start des neuen Entwicklersystems würde natürlich auch ne Sparversion genügen, die alles plattmacht und dann die Daten mit Original-IDs rüberzieht; Updatefunktion gesperrt. Aber ich denke der Mehraufwand für die volle Funktionalität hält sich wirklich in vertretbaren Grenzen.

#10 Updated by following almost 6 years ago

following schrieb:

  • Import der Empfehlungen fehlt

... und macht bei dem, was das XML-Interface im Moment liefert auch nur begrenzt Sinn. Habe die Ausgabe von Empfehlungen per XML überarbeitet (#244); das ist jetzt er mal im Test, als neue XML-Version 1.4.

Gleichzeitig habe ich auch zwei neue Felder für caches.listing_last_modified und cache_logs.logs_last_modified eingebaut, die ebenfalls noch in die Replikation mit rein sollten.

#11 Updated by following about 4 years ago

  • Assignee deleted (Sampiero)

#12 Updated by following about 3 years ago

Alle Abhängigkeiten von @XMLSYNC in den DB-Triggern sind zu prüfen; da wird einiges zu viel abgeschaltet.

#13 Updated by teiling88 over 2 years ago

  • Tracker changed from Orga to Feature
  • Target version set to Version 3.2.0

#14 Updated by following almost 2 years ago

  • Status changed from in Arbeit 20% to offen
  • Assignee set to following
  • Target version changed from Version 3.2.0 to Version 3.1.5
  • % Done changed from 20 to 0

#15 Updated by following almost 2 years ago

  • Target version changed from Version 3.1.5 to Version 3.2.0

#16 Updated by following almost 2 years ago

Um dieses Feature bereitzustellen wären zwei Schritte nötig:

1. Update des XML-Interface; zumindest die Cachelisten fehlen dort noch.
2. Komplettüberarbeitung oder Neuschreiben des XML-Importscripts

Die Änderungen würden sich auf drei Stellen konzentrieren:
  • htdocs/xml, ein paar dutzend zusätzliche Codezeilen
  • local/ocxml11client, einige hundert neue/geänderte Codezeilen
  • sql/stored-proc, ein paar IF-Statements sind anzupassen, Stichwort "@XMLSYNC"

Am übrigen Code gäbe es nur minimale Änderungen.

Nutzen / Vorteile:
  • Der bereitgestellte Datenbankdump reduziert sich auf die statischen GeoDB- und NSG-Daten, kann somit keinen problematischen Content mehr enthalten (z.B. mittlerweile gesperrte/versteckte Caches).
  • Die Entwickler können sich immer auf die aktuellsten Produktivdaten updaten (wobei dann die ID-Felder für neue Caches, Logs usw. umgemappt werden, damit es nicht mit vorhandenen Testdaten kollidiert).
  • Mögliche Leaks von nichtöffentlichen Daten durch Lücken in strip_private_data würden ausgeschlossen (aktuell z.B. möglich bei bestimmten Datenbank-Inkonsistenzen).
  • Wer seine Datenbank kompakt halten will, kann sich auch nur die Daten ab Tag X ziehen (z.B. alle ab 1.1.2017 veröffentlichten Caches mit Logs).
  • Mögliche systematische Fehler bei der Datenbereitstellung für die Entwicklersysteme würden aufgedeckt (vgl. #242).
  • Die gewonnenen Erkenntisse wären teils für #840 wiederverwertbar.
  • Wir hätten danach ein renoviertes XML-Interface.
Nachteile:
  • Die vollständige Initialisierung des Entwicklersystems dauert wesentlich länger, weil Suchindex, geographische Cache-Informationen, Statistiken etc. lokal neu generiert werden müssen (der Code dafür ist bereits vorhanden). Nach einem Komplettimport kann das Stunden dauern, kann allerdings überwiegend asynchron laufen, während das System bereits genutzt wird.
  • Inkonsistenzen/Fehler der Produktivdatenbank - z.B. verwaiste Tabellenzeilen - würden nicht mitkopiert und wären somit auf dem Entwicklersystem nicht nachvollziehbar.

Ich kann das Ganze allerdings nur im alten Framework und ohne Unit Tests bereitstellen. Bitte um eine Entscheidung, ob das so erwünscht ist.

Vorab würde ich dann nochmal prüfen, ob wirklich alle relevanten Daten per XML-Interface bereitstellbar sind, sodass am Ende tatsächlich dasselbe dabei herauskommt wie bei einer "gestrippten" Original-Produktivdatenbank.

#17 Updated by following almost 2 years ago

Der Datenbankdump wäre dann sogar optional, er würde nur noch für die regionale Zuordnung der Caches benötigt.

#18 Updated by following almost 2 years ago

#19 Updated by following over 1 year ago

  • Assignee deleted (following)

Also available in: Atom PDF