Wozu wird die changes.sql eigentlich generiert? Nutzen kann man diese Datei wegen des durchweg inkonsistenten Datenbestandes nicht. Wie in verschiedenen Fragen hier im Forum bereits formuliert ist die Nutzung der changes.sql in Kombination mit einem Dump um einen aktuellen Datenbestand zu erreichen nicht möglich.
Die changes.sql als "Dokumentationshilfe" zu sehen oder auf die tab Dateien zu verweisen ist ein schwacher Trost.
Ein Vorschlag wäre alle paar Monate einen frischen Dump zu erstellen und auf die nutzlose changes.sql zu verzichten.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wie in verschiedenen Antworten im Forum formuliert ist es sehr wohl möglich, damit einen aktuellen Datenbestand zu erreichen.
Dein Serviceanspruch wirkt recht hoch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-10-15
Wegen den Inkosistenzen ist eben nicht möglich so wie in der Dokumentation beschrieben.
Ein "Serviceanspruch" habe ich wahrlich nicht. Jedes mal wenn ein Vorschlag gemacht wird, der vom Betreiber eines OS Projekts abhängt, unterstellt man gleich eine Anspruchshaltung.
Wenn es zu viel verlangt ist alle paar Monate(!) einen aktuellen Dump zur Verfügung zu stellen, wird der Betreiber seinem Projekt in meinen Augen nicht gerecht. Ganz zu schweigen, das die Zuarbeit der freiwilligen Pfleger der changes dadurch ad absurdum geführt wird.
Ich habe höchsten den Wunsch, das diese Arbeit gewürdigt wird, indem man alle drei Monate einen Dump erstellt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Drei Monate können ein sinnvoller Zeitraum sein - das ist ein angemessener und konstruktiver Vorschlag.
Welche Inkonsistenzen stellst du denn aktuell fest, die in den letzten drei Monaten erfolgt wären, oder seit dem letzten Dump vor 12 Monaten?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-10-17
Viele der INSERTS der changes.sql sind entweder Werteredundant oder mit Abweichung im letzten Dump enthalten. Dadurch kann ein normaler User den letzten Dump (Okt/2011) mit der changes.sql nicht aktualisieren. Sicher kann man das zusammenbasteln, aber das ist nicht wirklich attraktiv.
Abgesehen davon wäre es für das Projekt auch förderlich, wenn ein Dump deutlich kommuniziert würde und so jeder schnell den letzten Stand zu fassen bekommt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wie schon mehrfach kommuniziert nimmt man sich daher aus den changes.sql nur alle Werte ab dem letzten dump.
Ist das zu viel Basteln?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-10-17
Für mich nicht, aber ein solides Angebot sieht anders aus.
Mein Vorschlag alle paar Monate ein Dump bereitzustellen würde für die Masse an Interessierten die attraktivste Variante sein. Mit der changes.sql müssen sich dann nur die befassen, welche es warum auch immer müssen.
Das ist keine Frage des Aufwands sondern der Transparenz. Momentan verliert das Projekt aufgrund solcher unnötigen Sachen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Die .tab sind kein solides Angebot, sondern ein funktionierender Workaround, so lange bis jemand irgendwo eine echte SQL-Datenbank mit Versionierung, Undo, Download und allem drum und dran ins Netz stellt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-10-17
Von den Tabs hab ich auch nicht gesprochen.
Ist zwar Offtopic, aber Du sprichst von einer "echten" SQL-Datenbank. Soweit ich weiß arbeitet das momentane Wartungstool auf Dateiebene, also auf den Tabs richtig?
Danke übrigens für den Dump.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aktuellere Dumps brauche ich ja nicht, wenn ich einen Zusammenhang verstehen würde:
Wenn die changes.sql Datensätze aus dem Dump aktualisieren, wie stelle ich den Zusammenhang her?
Beispiel Mannheim loc_id 20600:
Der Name ist am 13.5. von "Mannheim, Universitätsstadt" in "Mannheim" geändert worden (Sehe ich online wunderbar). In den Changes.sql ist nur der Insert zu sehen. Wie kann ich den Zusammenhang herstellen, dass es sich um ein Aktualisierung handelt und nicht um einen neuen Eintrag? Und wie würde sich eine PLZ, die üngültig geworden ist, in den changes.sql darstellen?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wenn die changes.sql Datensätze aus dem Dump aktualisieren, wie stelle
ich den Zusammenhang her?
Hallo Saskia,
bisher enthalten die changes.sql generell nur INSERT-Befehle. Ob ein
UPDATE oder DELETE damit kombiniert werden muss, das muss der Anwender
derzeit selbst entscheiden.
Beispiel Mannheim loc_id 20600:
Der Name ist am 13.5. von "Mannheim, Universitätsstadt" in "Mannheim"
geändert worden (Sehe ich online wunderbar). In den Changes.sql ist nur
der Insert zu sehen. Wie kann ich den Zusammenhang herstellen, dass es
sich um ein Aktualisierung handelt und nicht um einen neuen Eintrag?
Du musst bei jedem INSERT prüfen, ob es dafür bereits einen Eintrag gibt
und diesen ggf. löschen.
Und
wie würde sich eine PLZ, die üngültig geworden ist, in den changes.sql
darstellen?
Gute Frage, da müsste ich selbst nachsehen...
Für eine spätere Version kann ich mir vorstellen, REPLACE, UPDATE,
DELETE den changes.sql hinzuzufügen. Da bin ich aber zu wenig Experte,
sondern brauche vorgefertigte und allgemein anerkannt gültige Beispiele,
was von SQL generell unterstützt wird. Beispielsweise bin ich mir nicht
sicher, ob REPLACE speziell von MySQL unterstützt wird, oder generell
zur SQL-Syntax gehört.
Alles, was ich selbst machen werde, ist eine Übersetzung der online
erfolgten Eingabe oder Korrektur in einen solchen SQL-Befehl für
die changes.sql-Datei.
Schönen Gruß
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Der REPLACE ist (soweit ich es gesehen habe) eine Eigenheit von MySQL, der aber nur bei einem Unique Index/Primary Key funktioniert. Genau die Bedingung kann ich nicht erfüllen (zumindest sehe ich es nicht), denn auf der textdata will ich ja nur einen Namen zulassen (textval wäre nicht Bestandteil des Index), aber mehrere Postleitzahlen (hier wäre textval Bestandteil des Index).
Beim Rumstöbern bin ich noch auf den MERGE-Befehl gestoßen, des Standard sein soll, mir aber zu kompliziert von der Syntax her erscheint.
Schön würde ich finden, wenn die Valid-Felder (since und until) benutzt werden. Denn bei einer Änderung/Löschung eines Datensatzes wird dieser auf gültig bis heute/gestern gesetzt (als UPDATE in der changes) und die Änderung kommt dann als INSERT mit gültig von heute bis unendlich. Die Löschung ist mit Invalid setzen abgedeckt. So wäre ich in der Lage die Änderung ohne Prüfung zu übernehmen.
Vielleicht hast du auch einen besseren Weg im Sinn.
Viele Grüße
p.s. Für die Postleitzahl habe ich mal ein Beispiel bereitgestellt, denn laut post.de hat Schenkdorf bei KW/Mittenwalde nur die 15749. Da ich es nicht besser wusste, habe die 15711 auf 15749 geändert.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wozu wird die changes.sql eigentlich generiert? Nutzen kann man diese Datei wegen des durchweg inkonsistenten Datenbestandes nicht. Wie in verschiedenen Fragen hier im Forum bereits formuliert ist die Nutzung der changes.sql in Kombination mit einem Dump um einen aktuellen Datenbestand zu erreichen nicht möglich.
Die changes.sql als "Dokumentationshilfe" zu sehen oder auf die tab Dateien zu verweisen ist ein schwacher Trost.
Ein Vorschlag wäre alle paar Monate einen frischen Dump zu erstellen und auf die nutzlose changes.sql zu verzichten.
Wie in verschiedenen Antworten im Forum formuliert ist es sehr wohl möglich, damit einen aktuellen Datenbestand zu erreichen.
Dein Serviceanspruch wirkt recht hoch.
Wegen den Inkosistenzen ist eben nicht möglich so wie in der Dokumentation beschrieben.
Ein "Serviceanspruch" habe ich wahrlich nicht. Jedes mal wenn ein Vorschlag gemacht wird, der vom Betreiber eines OS Projekts abhängt, unterstellt man gleich eine Anspruchshaltung.
Wenn es zu viel verlangt ist alle paar Monate(!) einen aktuellen Dump zur Verfügung zu stellen, wird der Betreiber seinem Projekt in meinen Augen nicht gerecht. Ganz zu schweigen, das die Zuarbeit der freiwilligen Pfleger der changes dadurch ad absurdum geführt wird.
Ich habe höchsten den Wunsch, das diese Arbeit gewürdigt wird, indem man alle drei Monate einen Dump erstellt.
Drei Monate können ein sinnvoller Zeitraum sein - das ist ein angemessener und konstruktiver Vorschlag.
Welche Inkonsistenzen stellst du denn aktuell fest, die in den letzten drei Monaten erfolgt wären, oder seit dem letzten Dump vor 12 Monaten?
Viele der INSERTS der changes.sql sind entweder Werteredundant oder mit Abweichung im letzten Dump enthalten. Dadurch kann ein normaler User den letzten Dump (Okt/2011) mit der changes.sql nicht aktualisieren. Sicher kann man das zusammenbasteln, aber das ist nicht wirklich attraktiv.
Abgesehen davon wäre es für das Projekt auch förderlich, wenn ein Dump deutlich kommuniziert würde und so jeder schnell den letzten Stand zu fassen bekommt.
Wie schon mehrfach kommuniziert nimmt man sich daher aus den changes.sql nur alle Werte ab dem letzten dump.
Ist das zu viel Basteln?
Für mich nicht, aber ein solides Angebot sieht anders aus.
Mein Vorschlag alle paar Monate ein Dump bereitzustellen würde für die Masse an Interessierten die attraktivste Variante sein. Mit der changes.sql müssen sich dann nur die befassen, welche es warum auch immer müssen.
Das ist keine Frage des Aufwands sondern der Transparenz. Momentan verliert das Projekt aufgrund solcher unnötigen Sachen.
Die .tab sind kein solides Angebot, sondern ein funktionierender Workaround, so lange bis jemand irgendwo eine echte SQL-Datenbank mit Versionierung, Undo, Download und allem drum und dran ins Netz stellt.
Ansonsten: ein neuer Dump steht nun zur Verfügung
6475978 2011-10-17 18:13 opengeodb-02624_2011-10-17.sql.gz
Von den Tabs hab ich auch nicht gesprochen.
Ist zwar Offtopic, aber Du sprichst von einer "echten" SQL-Datenbank. Soweit ich weiß arbeitet das momentane Wartungstool auf Dateiebene, also auf den Tabs richtig?
Danke übrigens für den Dump.
> Soweit ich weiß arbeitet das momentane Wartungstool auf Dateiebene, also auf den Tabs richtig?
Ganz richtig
Leider ist wieder fast ein Jahr vergangen seit dem letzten Dump. Ist wohl nicht drin alle paar Monate einen für die Masse der Leute zu erzeugen?
Leider kann ich auf dem Server nicht selbst cron jobs anlegen, sondern muss es händisch starten.
Kurze Anfrage reicht also, um einen neuen dump so zeitnah wie möglich zu bekommen.
Anfrage ist da ;)
Muss es ein Cronjob direkt vom Server sein? Ansonsten bieten sich ja auch externe Cronjobdienste an.
Nein, von extern wird noch nichts unterstützt.
Die Anfrage ist schon erledigt :-)
Wie wärs mit einem Dump im Jahr 2013?
Aktuellere Dumps brauche ich ja nicht, wenn ich einen Zusammenhang verstehen würde:
Wenn die changes.sql Datensätze aus dem Dump aktualisieren, wie stelle ich den Zusammenhang her?
Beispiel Mannheim loc_id 20600:
Der Name ist am 13.5. von "Mannheim, Universitätsstadt" in "Mannheim" geändert worden (Sehe ich online wunderbar). In den Changes.sql ist nur der Insert zu sehen. Wie kann ich den Zusammenhang herstellen, dass es sich um ein Aktualisierung handelt und nicht um einen neuen Eintrag? Und wie würde sich eine PLZ, die üngültig geworden ist, in den changes.sql darstellen?
On 13-06-07 16:23, Saskia Bikle wrote:
Hallo Saskia,
bisher enthalten die changes.sql generell nur INSERT-Befehle. Ob ein
UPDATE oder DELETE damit kombiniert werden muss, das muss der Anwender
derzeit selbst entscheiden.
Du musst bei jedem INSERT prüfen, ob es dafür bereits einen Eintrag gibt
und diesen ggf. löschen.
Gute Frage, da müsste ich selbst nachsehen...
Für eine spätere Version kann ich mir vorstellen, REPLACE, UPDATE,
DELETE den changes.sql hinzuzufügen. Da bin ich aber zu wenig Experte,
sondern brauche vorgefertigte und allgemein anerkannt gültige Beispiele,
was von SQL generell unterstützt wird. Beispielsweise bin ich mir nicht
sicher, ob REPLACE speziell von MySQL unterstützt wird, oder generell
zur SQL-Syntax gehört.
Alles, was ich selbst machen werde, ist eine Übersetzung der online
erfolgten Eingabe oder Korrektur in einen solchen SQL-Befehl für
die changes.sql-Datei.
Schönen Gruß
Martin
Hallo Martin,
Der REPLACE ist (soweit ich es gesehen habe) eine Eigenheit von MySQL, der aber nur bei einem Unique Index/Primary Key funktioniert. Genau die Bedingung kann ich nicht erfüllen (zumindest sehe ich es nicht), denn auf der textdata will ich ja nur einen Namen zulassen (textval wäre nicht Bestandteil des Index), aber mehrere Postleitzahlen (hier wäre textval Bestandteil des Index).
Beim Rumstöbern bin ich noch auf den MERGE-Befehl gestoßen, des Standard sein soll, mir aber zu kompliziert von der Syntax her erscheint.
Schön würde ich finden, wenn die Valid-Felder (since und until) benutzt werden. Denn bei einer Änderung/Löschung eines Datensatzes wird dieser auf gültig bis heute/gestern gesetzt (als UPDATE in der changes) und die Änderung kommt dann als INSERT mit gültig von heute bis unendlich. Die Löschung ist mit Invalid setzen abgedeckt. So wäre ich in der Lage die Änderung ohne Prüfung zu übernehmen.
Vielleicht hast du auch einen besseren Weg im Sinn.
Viele Grüße
p.s. Für die Postleitzahl habe ich mal ein Beispiel bereitgestellt, denn laut post.de hat Schenkdorf bei KW/Mittenwalde nur die 15749. Da ich es nicht besser wusste, habe die 15711 auf 15749 geändert.