Feature #25

XML-Datenimport von OC.de im Entwicklersystem

Von following vor fast 6 Jahren hinzugefügt. Vor mehr als 1 Jahr aktualisiert.

Status:offen% erledigt:

0%

Priorität:2 mittel
Zugewiesen an:-
Zielversion:Version 3.2.0
Ticket Referenz: Kategorien:import

Zugehörige Tickets

Beziehung mit OC Entwicklung - Orga #9: neues Entwicklersystem einrichten erledigt
Beziehung mit OC Entwicklung - Change #243: XML-Client-Reimport verwirft abhängige lokale Daten verworfen
Blockiert durch OC Entwicklung - Feature #1115: XML-Interface aktualisieren neu

Historie

#1 Von following vor fast 6 Jahren aktualisiert

  • Thema wurde von XML-Datenimport von OC.de im neuen Entwicklersystem zu XML-Datenimport von OC.de im Entwicklersystem geändert
  • Zugewiesen an wurde auf Sampiero gesetzt
  • Geschätzter Aufwand 30.00 wurde gelöscht

#2 Von following vor fast 6 Jahren aktualisiert

  • Kategorien wurde auf import gesetzt

#3 Von Sampiero vor fast 6 Jahren aktualisiert

  • Status wurde von offen zu in Arbeit 20% geändert
  • % erledigt wurde von 0 zu 10 geändert

#4 Von Sampiero vor fast 6 Jahren aktualisiert

  • % erledigt wurde von 10 zu 50 geändert

#5 Von Sampiero vor fast 6 Jahren aktualisiert

  • % erledigt wurde von 50 zu 80 geändert

#6 Von following vor mehr als 5 Jahren aktualisiert

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

#7 Von Sampiero vor mehr als 5 Jahren aktualisiert

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

#8 Von following vor mehr als 5 Jahren aktualisiert

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 Von following vor mehr als 5 Jahren aktualisiert

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 Von following vor mehr als 5 Jahren aktualisiert

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 Von following vor mehr als 3 Jahren aktualisiert

  • Zugewiesen an Sampiero wurde gelöscht

#12 Von following vor mehr als 2 Jahren aktualisiert

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

#13 Von teiling88 vor etwa 2 Jahren aktualisiert

  • Tracker wurde von Orga zu Feature geändert
  • Zielversion wurde auf Version 3.2.0 gesetzt

#14 Von following vor mehr als 1 Jahr aktualisiert

  • Status wurde von in Arbeit 20% zu offen geändert
  • Zugewiesen an wurde auf following gesetzt
  • Zielversion wurde von Version 3.2.0 zu Version 3.1.5 geändert
  • % erledigt wurde von 20 zu 0 geändert

#15 Von following vor mehr als 1 Jahr aktualisiert

  • Zielversion wurde von Version 3.1.5 zu Version 3.2.0 geändert

#16 Von following vor mehr als 1 Jahr aktualisiert

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 Von following vor mehr als 1 Jahr aktualisiert

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

#18 Von following vor mehr als 1 Jahr aktualisiert

  • Blockiert durch Feature #1115: XML-Interface aktualisieren wurde hinzugefügt

#19 Von following vor mehr als 1 Jahr aktualisiert

  • Zugewiesen an following wurde gelöscht

Auch abrufbar als: Atom PDF