Fragen-Liste

Aus kvwmap
Wechseln zu: Navigation, Suche

Fragen zu Funktionen, "wie haben andere das gemacht?"

Zur Aktualisierung von Systemen im laufendem Betrieb

neues Konzept

In mehreren Kreisverwaltungen gibt es zwei Systeme. Ein Testsystem A, auf dem laufend Änderungen am System erfolgen (also Versions-Updates, DB-Strukturänderungen, Datenänderungen) und ein Nutzersystem B auf dem die Nutzer arbeiten und auf dem Änderungen an den Daten stattfinden. Das Problem besteht nun darin, diese beiden Systeme zu synchronisieren, d.h. die Änderungen beider Systeme zusammenzuführen. Um dies tun zu können wurde ein Konzept entwickelt, welches folgende Schritte umfasst:

1. Die Ausgangssituation ist, dass beide Systeme A und B vollkommen identisch sind.

2. Nun beginnt die Datenänderungsphase: Auf dem Nutzerrechner (B) werden alle Aktionen, die die Nutzer durchführen (Hinzufügen, Ändern, Löschen von Daten) in zwei Log-Dateien (je eine für mysql und postgres) aufgezeichnet. Parallel dazu können auf dem Testrechner (A) Änderungen am System vorgenommen werden.

3. Jetzt werden die Systeme synchronisiert. Dazu wird der Betrieb auf beiden Systemen eingestellt und die Log-Dateien werden auf System A ausgeführt. Nach erfolgreichem Ausführen befinden sich alle Daten, die während der Datenänderungsphase auf System B aufgezeichnet wurden, nun auch auf System A.

4. Um den Nutzerrechner B auf den aktuellen Stand zu bringen, wird nun das gesamte System A nach B kopiert (Quellcode und Datenbanken)

5. weiter bei 1.

Um dieses Konzept zu realisieren, muss wie schon erwähnt, in kvwmap jede Datenbankaktion die die Nutzer ausführen können, in eine Log-Datei geschrieben werden. In der Version 1.6.0 wurden dabei folgende Nutzeraktionen berücksichtigt:

  • Nachweisverwaltung
  • Antragsverwaltung
  • Gutachterausschuss
  • Flächenversiegelung
  • Geothermie
  • Notizen
  • Druckrahmenverwaltung
  • automatische DB-Aktionen bei Systemnutzung (Rollenbezogene Eigenschaften, History, Zugriffsspeicherung)

bisheriges Konzept

Prizipiel könnte man natürlich die Änderungen für einen Versionswechsel auf dem laufenden System vornehmen. Dies würde aber zu Ausfällen führen können, wenn das Update nicht erfolgreich durchgeführt wurde oder sonstige unvorhersehbare Schwierigkeiten auftauchen. Unvorhergesehene Schwierigkeiten treten insbesondere dann auf, wenn der Benutzer zwischen zwei Updates schon selbständig Änderungen entweder am Datenmodell der Datenbanken oder in den Snippets vorgenommen hat. Es ist also anzuraten zunächst ein Testsystem (B) zu aktualisieren und nach erfolgreichem Update das Originalsystem (A) zu aktualisieren. Folgende Schritte sollten dabei berücksichtigt werden:

  1. Update-Test auf System B
    1. Aktuelle Datenbanken (mysql und postgres) von A nach B kopieren.
    2. Neue Version des Quellcodes auf B installieren und config.php an System anpassen.
    3. Eventuell eigene Snippets oder Grafiken einbinden.
    4. Datenbankupdates (postgres_update.sql und mysql_update.sql) auf B ausführen.
    5. alle notwendigen Änderungen an der Struktur der Datenbanken und an den Daten selbst gesondert notieren (z.B. in mysql_myupdate.sql und postgres_myupdate.sql).
    6. Testen des Systems B auf fehlerfreien Betrieb, d.h. alle wesentlichen Funktionen überprüfen
  2. Sicherung System A
    1. Kopieren der Datenbanken und Speicherung mit dem Namenszusatz der alten Versionsnummer, z.B. kvwmapdb -> kvwmapdb1.5.8
    2. Sichern des Quellcodes mit dem Namenszusatz der alten Versionnummer, z.B. in ein Verzeichnis kvwmap-1.5.8
  3. Update auf System A
    1. Quellcode von B nach A kopieren
    2. Datenbankupdates mit Hilfe der mysql_myupdate.sql und postgres_myupdate.sql auf A ausführen
    3. In der Konfigurationsdatei config.php die IP-Adresse auf das System A anpassen
  4. Test auf Sytem A
    1. Sollten im System A Probleme auftauchen, kann die vorhergehende Version mit Hilfe der in Schritt 2 erstellten Sicherung von A wiederhergestellt werden


SRID in PostGIS ändern

  • --Pkorduan 11:20, 20. Mär 2006 (CET) Wie ändere ich die SRID für eine Tabelle in PostGIS wo schon Daten mit der falschen SRID drin stehen?
Antwort
Ändere zunächst die Eintragung in der Tabelle geometry_columns. Am besten mit der Funktion
SELECT updategeometrysrid('your_table', 'geom_col', <new_srid>);

Der Tabellen- und Spaltenname müssen in Anführungsstrichen angegeben sein. Anschließend ändere die SRID´s der Geometrien in your_table.

SELECT setsrid(geom_col, <new_srid>) FROM your_table;

Hier den Spaltennamen nicht in Anführungsstrichen. Ein Beispiel:

SELECT updategeometrysrid('cities','the_geom',2398);
SELECT setsrid(the_geom,2398) FROM cities;


kvwmap-Datenbank - Trennung von ALK- und Sachdaten in PostgreSQL

--HolgerR 07:40, 19. Jun 2006 (CEST) Bei Änderungen in der Datenstruktur von EDBS2WKT muss grundsätzlich eine neue ALK-Datenbank angelegt werden, wie z.B. von der Version 1.6 zu 1.7. Das Handling zur Wiederherstellung und Nutzung der kvwmap-Datenbank ist zu umständlich, da die Sachdaten aus der alten kvwmap-Datenbank in die neue ALK-Datenbank eingelesen werden müssen um als neue kvwmap-Datenbank genutzt zu werden. Während dieser Zeit, Backup und Restore der alten kvwmap-Datenbank, dürfen keine Änderungen an den Daten vorgenommen werden, d.h. die Einarbeitung von Daten (Dokumentenverwaltung, Notizen, etc.) muss zu dieser Zeit ruhen.

--Markus Hentschel 14:46, 20. Jun 2006 (CEST)
Vielleicht sogar eine Trennung in 3 Datenbanken: ALK- ALB- und Geometriedatenbank?
--Pkorduan 17:47, 21. Jun 2006 (CEST)
Hier hilft sicher ein Skript, welches ein Backup nur von kvwmap-relevanten Datentabellen macht. Mir schwebt da vor, das das Backupskript das Skript zum Anlegen der Datenbank (postgis_install.sql) durchsucht nach CREATE Einträgen und den dazugehörigen Tabellennamen und anschließend zu jedem dieser Tabellen ein Dump mit oder ohne Daten anfertigt.
Andere Möglichkeit wäre ein Skript, welches alle ALK relevanten Tabellen vom EDBS2WKT Konverter löscht. Gab es da nicht mal was von Herrn Jäger? Wenn man also seine Datenbank von ALK-Tabellen befreit hätte, könnte man diese als Template zum Anlegen einer neuen ALK-Datenbank angeben und hätte schon alles von kvwmap drin.
Die Geschichte mit mehreren Datenbanken ginge vom Prinzip her auch, jedoch müßte man dann Joins über Datenbanken hinweg machen. Das ist schlecht. Über Schemas hinweg würde ja noch gehen, aber die liegen immer in ein und der selben Datenbank.
--HolgerR 15:27, 26. Jun 2006 (CEST)
Der 2.Tipp, alle relevanten Tabellen des EDBS2WKT-Koverters zu löschen (richtig, zu EDBS2WKT ist ein entsprechendes SQL-Skript beigelegt) und diese Datenbank dann als Template zu nutzen sollte vom Handling her funktionieren.
Herr Jäger hat ja die Version 1.7 vom EDBS2WKT-Konverter freigegeben, da ist das ein willkommener Anlass das Handling zu testen.
Nur die Benutzung der DB muss zu dieser Zeit ja trotzdem gesperrt werden, da ja die alte DB als Template dient und die neue DB einen anderen Namen erhalten muss. Nach Anlegen der DB, oder vielleicht schon vorher, sollten die alte und die neue DB umbenannt werden, damit in der config.php und der Layerverwaltung keine Änderungen vorgenommen werden müssen.
Sind die Laufzeitprobleme bei Joins über Datenbanken hinweg so gravierend, dass man lieber die Sperrung der Datenbank für eine gewisse Zeit in Kauf nehmen sollte?