Paul Puschmann schrieb:
> On Wed, Oct 11, 2006 at 09:33:16AM +0200, Sven Neuhaus wrote:
>
>> Martin Brenda wrote:
>>
>>> Es müssen auf jeden Fall zentrale IDs sein. Das Problem ist aber folgendes:
>>> wenn
>>> ich einen Ort in meiner DB brauche, dann brauche ich ihn sofort. Ich kann
>>> nicht
>>> die Daten an OpenGeoDB weiterleiten und dann auf das nächste Update warten.
>>> Wenn ich die Daten nun in meine DB einpflege und sie dann an OpenGeoDB
>>> weiterleite, dann würde ich gerne die loc_id beibehalten können bzw. sofort
>>> eine Nachricht bekommen, dass diese sich ändert und zwar in diese und diese
>>> neue loc_id. Dann kann ich die loc_id in meiner DB beibehalten bzw. gleich
>>> nachziehen. Ich habe keine Interesse, alle diese Abgleiche später, beim
>>> nächsten Update auf eine neue OpenGeoDB zu machen. Dies erschwert die
>>> Angelegenheit nur.
>>>
>> Man könnte einen solchen Mechanismus sicherlich aufsetzen, geprüft werden
>> können die Daten aber wohl nicht sofort, insofern kann es vorkommen dass
>> eine ID dann wieder entzogen wird, da der Datensatz nicht korrekt oder
>> ungültig war.
>>
>
> Ich würde alerdings vorschlagen die ID an dieser Stelle nicht "zu
> entziehen" und später einem anderen Eintrag zur Verfügung zu stellen,
> da die ID ja sicher in dem System des "Absenders" gespeichert ist.
> Ein ungültiger Antrag sollte dann zu einer gesperrten ID führen.
>
> So könnten auch Änderungen und Änderungswünsche sicher besser
> nachvollzogen werden.
>
>
>
>>> Ich glaube unsere Ansichten sind gar nicht so verschieden. Im Endeffekt
>>> müsste
>>> es eine zentrale Vergabe von loc_id's geben, ob automatisiert oder per Hand
>>> ist
>>> zweitrangig (automatisiert wäre aber sinnvoller, im Interesse des armen
>>> Hundes
>>> der die Dinger sonst per Hand vergeben muss). Falls die Vergabe automatisch
>>> erfolgen soll, so muss es irgendwo (ich nehme mal jetzt den Server an) eine
>>> "aktuelle" Version von OpenGeoDB geben. Dort könnte man 1) überprüfen ob der
>>> Ort, den ich eingeben will, nicht in der Zwischenzeit eingegeben wurde und
>>> 2)
>>> immer eine noch freie loc_id bekommen, falls der Ort nicht existiert.
>>>
>> Sehr hilfreich wäre in dem Zusammenhang auch wenn sich Benutzer, die
>> Korrekturen oder Ergänzungen haben, alle (teils noch ungeprüften)
>> Korrekturen einsehen können die seit dem letzten Release eingegangen sind -
>> und die vorläufigen IDs die Ihnen zugewiesen wurden. Damit wird verhindert
>> dass eine Korrektur mehrmals durchgeführt wird und mehrere vorläufige IDs
>> für dieselber Korrektur vergeben werden von denen dann doch eine wieder
>> entzogen wird.
>> Im Prinzip also eine Echtzeit-Ansicht eines Teils der OpenGeoDB.
>>
>
> Die Idee ist an sich gut.
>
> Kann ich unter einer vorläufigen ID soetwas wie eine
> Support-Ticket-Nummer verstehen, die lediglich meine Anfrage /
> Änderung nummeriert und dann später (nach erfolgreicher Prüfung) eine
> eindeutige ID zurückliefert?
>
Genau das halte ich für sinnvoll.
Wenn irgendwann die freien locids knapp werden, kann man ja eventuell
über die Einführung von Major-Releases nachdenken, die quasi nicht mehr
mit eigenen Datenbeständen kompatibel sind, dafür aber alle IDs komplett
wieder freigeben, die darin nicht enthalten sind.
Häufig wird dies nicht notwendig sein, aber für den Fall der Fälle wäre
das ein Ausweg. Auf diese Weise könnte man auch das Löschen nach einem
Monat oder einem Jahr oder so rauslassen, was zu mehr Verwirrung und
Problemen führen dürfte.
Im Großen und Ganzen liefe auf diese Weise das System tatsächlich auf
eine Art Bugtracking-System hinaus:
- Fehlermeldungen
- Bearbeitung der Fehler
- Feature-Wünsche
- Lösung/Einfügung der Features
zusätzlich:
- Direkte Fehlerkorrekturen/Einfügungen
> Hört sich soweit vom Ablauf interessant an.
>
> Paul
>
dito
Peter
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
|
