Ich habe die Tage mit dem in GitHub verfügbaren Code eine Installation in einer VirtualBox-VM (Debian 7) gemacht und mit dem ocxml11client alle verfügbaren Daten importiert.
Der Import hat bis auf ein paar XML-Aussetzer ganz gut funktioniert, es ist jetzt ganz sicher kein 1:1-Dump aber die Daten reichen zum lokalen Entwickeln. Auch CentOS <-> Debian ist da denke ich kein großes Hindernis.
Meine Frage: Darf ich eine auf diese Weise erzeugte VM weitergeben oder greift hier wieder die selbe Problematik weswegen das alte Entwicklersystem nicht mehr verfügbar ist?
Entwicklersystem
-
following
Oh, ich hätte nicht gedacht dass der XML-Client nach all den Datenbankänderungen überhaupt noch funktioniert. Sehr schön. 
Das alte Entwicklersystem kann durchaus weitergegeben werden, solange klar ist dass die Daten nur für persönliche Testzwecke verwendet werden. Die Verantworung für eine Veröffentlichung würde ich nicht tragen wollen, weil z.B. Daten enthalten sein können die inzwischen aus rechtlichen Gründen auf OC.de nicht mehr sichtbar sind.
Ich denke das gilt gleichermaßen für das System, das du zusammengebaut hast: Es liegt bei dir, was du verantworten kannst/möchtest. Bei einer Weitergabe an einzelne Entwickler sehe ich kein Problem. Was dann wahrscheinlich noch nachgefragt werden wird ist eine Installationsanleitung (VM einrichten, Netzwerk einrichten, Git-Konfiguration vornehmen...) und Support für die Entwickler, die das nicht alleine hinbekommen.
Das bestehende, alte Entwicklersystem hat noch zwei Hauptprobleme, nachdem das dritte Problem - schwere Wartbarkeit - durch die neue Datenbankversionierung entschärft wurde:
- Es ist für Entwickler ohne oder mit wenig Linux-Kenntnissen recht anspruchsvoll zu installieren, auch wenn es eine detaillierte Anleitung dafür gibt.
- Wir können es nicht mit Echtdaten veröffentlichen, die man für realistische Tests braucht.
Der ersterer Punkt soll beim geplanten neuen System mit zusätzlichen Scripten + Web-Frontend für Installation/Konfiguration gelöst werden.
Das zweite Problem möchte ich lösen, indem ein System mit ein paar reinen Testdatensätzen veröffentlicht wird, dass die Entwickler dann selbst mit Inhalt füllen - am besten über ein vollautomatisches Script per XML-Client, notfalls über einen auf Anfrage erhältlichen Datenbankdump.
Bekommst du das XML-Teil so hin, dass das ohne manuellen Eingriff durchläuft? Datenbank leeren + wieder neu füllen? Das wäre ideal und könnte dann auch im neuen CentOS-Entwicklersystem verwendet werden. Dann baue ich auch gerne noch die zusätzlichen Wegpunkte und weitere fehlende Details ins XML-Interface rein, sodass die Daten tatsächlich komplett rüberkommen.
Das alte Entwicklersystem kann durchaus weitergegeben werden, solange klar ist dass die Daten nur für persönliche Testzwecke verwendet werden. Die Verantworung für eine Veröffentlichung würde ich nicht tragen wollen, weil z.B. Daten enthalten sein können die inzwischen aus rechtlichen Gründen auf OC.de nicht mehr sichtbar sind.
Ich denke das gilt gleichermaßen für das System, das du zusammengebaut hast: Es liegt bei dir, was du verantworten kannst/möchtest. Bei einer Weitergabe an einzelne Entwickler sehe ich kein Problem. Was dann wahrscheinlich noch nachgefragt werden wird ist eine Installationsanleitung (VM einrichten, Netzwerk einrichten, Git-Konfiguration vornehmen...) und Support für die Entwickler, die das nicht alleine hinbekommen.
Das bestehende, alte Entwicklersystem hat noch zwei Hauptprobleme, nachdem das dritte Problem - schwere Wartbarkeit - durch die neue Datenbankversionierung entschärft wurde:
- Es ist für Entwickler ohne oder mit wenig Linux-Kenntnissen recht anspruchsvoll zu installieren, auch wenn es eine detaillierte Anleitung dafür gibt.
- Wir können es nicht mit Echtdaten veröffentlichen, die man für realistische Tests braucht.
Der ersterer Punkt soll beim geplanten neuen System mit zusätzlichen Scripten + Web-Frontend für Installation/Konfiguration gelöst werden.
Das zweite Problem möchte ich lösen, indem ein System mit ein paar reinen Testdatensätzen veröffentlicht wird, dass die Entwickler dann selbst mit Inhalt füllen - am besten über ein vollautomatisches Script per XML-Client, notfalls über einen auf Anfrage erhältlichen Datenbankdump.
Bekommst du das XML-Teil so hin, dass das ohne manuellen Eingriff durchläuft? Datenbank leeren + wieder neu füllen? Das wäre ideal und könnte dann auch im neuen CentOS-Entwicklersystem verwendet werden. Dann baue ich auch gerne noch die zusätzlichen Wegpunkte und weitere fehlende Details ins XML-Interface rein, sodass die Daten tatsächlich komplett rüberkommen.
Zuletzt geändert von following am 10.05.2013, 01:38, insgesamt 1-mal geändert.
-
Sampiero
[quote="following"]
Bekommst du das XML-Teil so hin, dass das ohne manuellen Eingriff durchläuft? Datenbank leeren + wieder neu füllen? Das wäre ideal und könnte dann auch im neuen CentOS-Entwicklersystem verwendet werden. Dann baue ich auch gerne noch die zusätzlichen Wegpunkte und weitere fehlende Details ins XML-Interface rein, sodass die Daten tatsächlich komplett rüberkommen.[/quote]
Das kann ich gerne probieren, ich würde dann allerdings gleich ein neues Verzeichnis ("ocxml11client2") nutzen. Was gibt es denn bei zusätzlichen Wegpunkten und den weiteren fehlenden Details konkret zu beachten?
Bekommst du das XML-Teil so hin, dass das ohne manuellen Eingriff durchläuft? Datenbank leeren + wieder neu füllen? Das wäre ideal und könnte dann auch im neuen CentOS-Entwicklersystem verwendet werden. Dann baue ich auch gerne noch die zusätzlichen Wegpunkte und weitere fehlende Details ins XML-Interface rein, sodass die Daten tatsächlich komplett rüberkommen.[/quote]
Das kann ich gerne probieren, ich würde dann allerdings gleich ein neues Verzeichnis ("ocxml11client2") nutzen. Was gibt es denn bei zusätzlichen Wegpunkten und den weiteren fehlenden Details konkret zu beachten?
-
following
Beim Import der Wegpunkte muss man dann darauf achten, dass die Datumsfelder richtig gesetzt werden - d.h. coordinates.date_created und last_modified. Das hatte ich aber in den Triggern coordinatesBeforeInsert und coordinatesBeforeUpdate schon berücksichtigt.
Ich baue die fehlenden Informationen gleich mal ins XML-Interface ein, das hatte ich eh vor.
Ich baue die fehlenden Informationen gleich mal ins XML-Interface ein, das hatte ich eh vor.
-
following
Die Datumsfelder bei den zusätzlichen Wegpunkten habe ich weggelassen - es geht auch ohne. Ich hatte sie hauptsächlich wegen des XML-Interface eingebaut, es nun aber aus Performance-Gründen anders gelöst (caches.last_modified wird bei Wegpunktänderungen aktualisiert).
Doku der Änderungen: http://www.opencaching.de/doc/xml/ - Version 1.3
Das wär ne geile Sache wenn das mit dem XML-Client funktioniert - dann hätten wir alle Bausteine zusammen, um eine vollwertige OC-Entwicklungsumgebung mit allen Dokumentationen öffentlich bereitzustellen.
Doku der Änderungen: http://www.opencaching.de/doc/xml/ - Version 1.3
Das wär ne geile Sache wenn das mit dem XML-Client funktioniert - dann hätten wir alle Bausteine zusammen, um eine vollwertige OC-Entwicklungsumgebung mit allen Dokumentationen öffentlich bereitzustellen.
Zuletzt geändert von following am 10.05.2013, 21:18, insgesamt 1-mal geändert.
-
Sampiero
Hm... zwei Fragen:
1. Meine dbupdate.php funktioniert nicht richtig (mit dem aktuellsten git-Stand):
2. Import: In welche Tabelle kommen die Informationen aus der Node <wpts>?
1. Meine dbupdate.php funktioniert nicht richtig (mit dem aktuellsten git-Stand):
PHP 1. {main}() /home/oc/oc-server3/htdocs/doc/sql/stored-proc/maintain.php:0
updating OKAPI database
SQL Error 1146: Table 'ocdevel.okapi_vars' doesn't exist
The query was:
select var, value
from okapi_vars
PHP Fatal error: Call to undefined function okapi\getallheaders() in /home/oc/oc-server3/htdocs/okapi/core.php on line 207
PHP Stack trace:
PHP 1. okapi\OkapiExceptionHandler::handle() /home/oc/oc-server3/htdocs/okapi/core.php:0
PHP 2. okapi\OkapiExceptionHandler::get_exception_info() /home/oc/oc-server3/htdocs/okapi/core.php:123
Call to undefined function okapi\getallheaders()
PHP Fatal error: Call to undefined function okapi\getallheaders() in /home/oc/oc-server3/htdocs/okapi/core.php on line 207
PHP Stack trace:
PHP 1. okapi\OkapiExceptionHandler::handle() /home/oc/oc-server3/htdocs/okapi/core.php:0
PHP 2. okapi\OkapiExceptionHandler::get_exception_info() /home/oc/oc-server3/htdocs/okapi/core.php:123
PHP 3. okapi\OkapiErrorHandler::handle_shutdown() /home/oc/oc-server3/htdocs/okapi/core.php:0
PHP 4. okapi\OkapiExceptionHandler::handle() /home/oc/oc-server3/htdocs/okapi/core.php:256
PHP 5. okapi\OkapiExceptionHandler::get_exception_info() /home/oc/oc-server3/htdocs/okapi/core.php:123
2. Import: In welche Tabelle kommen die Informationen aus der Node <wpts>?
-
following
Oops. Das Script setzt voraus, dass die OKAPI installiert ist.Sampiero hat geschrieben: 1. Meine dbupdate.php funktioniert nicht richtig (mit dem aktuellsten git-Stand):
PHP 1. {main}() /home/oc/oc-server3/htdocs/doc/sql/stored-proc/maintain.php:0
updating OKAPI database
SQL Error 1146: Table 'ocdevel.okapi_vars' doesn't exist
OKAPI installieren:
1. Der OC-Datenbankuser braucht LOCK-Rechte.
2. httpd.conf (absoluten Pfad zum OKAPI-Verzeichnis einsetzen):
Code: Alles auswählen
<Directory .../htdocs/okapi>
Options FollowSymLinks
AllowOverride All
php_value short_open_tag 1
php_admin_value safe_mode "off"
</Directory>
4. Auf der lokalen Website okapi/update aufrufen und die Settings prüfen.
5. okapi/update?install=1
6. okapi/cron5 (kann ein paar Minuten dauern)
Dein Datenbankupdate ist ansonsten aber korrekt durchgelaufen, die OKAPI-Fehler beeinträchtigen nicht den Rest. Ich werde noch einen OKAPI-Test in das Script einbauen.
nach coordinates, mit type=1 und subtype=XML-'type'2. Import: In welche Tabelle kommen die Informationen aus der Node <wpts>?
-
Sampiero
Der Import tut eigentlich soweit, allerdings bleibt bei mir die Seite "neueste Logs" leer, obwohl ich die Daten eigentlich korrekt importiert habe. :/
-
following
Kann es sein, dass der Inhalt irgendwelcher statischen Tabellen fehlt? Die beiden SQLs oben in newlogs.php machen diverse Inner Joins ...
Ansonsten fällt mir noch das Template-Caching ein, aber falls du mit Admin-Rechten eingeloggt bists wird nix gecacht, und sonst nur für 5 Minuten. Evtl. mal das Caching in newlogs.php abschalten?
In deinem Stand von 20.5. im Github ist mir noch ein Missverständnis aufgefallen:
Das sollte heißen:
Ansonsten fällt mir noch das Template-Caching ein, aber falls du mit Admin-Rechten eingeloggt bists wird nix gecacht, und sonst nur für 5 Minuten. Evtl. mal das Caching in newlogs.php abschalten?
In deinem Stand von 20.5. im Github ist mir noch ein Missverständnis aufgefallen:
Code: Alles auswählen
$wpt['type'],
'XML-'.$wpt['type'],
Code: Alles auswählen
1,
$wpt['type'],