Bug oder Feature?

[MiK]

Die Quellen für Inkonsistenzen können nie ganz beseitigt werden, solange man die Daten doppelt hält. Selbst wenn CW perfekt wäre, können immer noch Äußere Einflüsse für inkonsistenzen führen. Deshalb bin ich dafür, dass der Index komplett neu anhand der Cache.xml-Files aufgebaut wird. Klar kann das auch mal länger dauern. Aber das sollte auch kein alltägliches Vorgehen sein, sondern eher ein Emergency Recovery.

 

[pfeffer]

ich wollte eben dargelegt haben, dass das ein sinnvolles, alltäglich vorgehen sein kann.
Ich vermute gar, dass dadurch die von vielen offenbar geführten "Profile" mit nur Founds oder nur interessanten und noch zu machenden Caches überflüssig werden.

Deswegen wäre ich für eine enstepchende Wahlmöglichkeit.

Gruß,
Pfeffer.

 

[pfeffer]

Das bedeutet, der einzige Ausweg aus der Inkonistenz ist: index.xml immer speichern und die Abfrage beseitigen.
1. Darf ich das so machen?

Der einzige Ausweg - pah! ;-) Probleme sind nur Ansätze für Lösungen ;-)
Meine Lösung in diesem Fall:
Wird eine <cache>.xml geschrieben mit Daten, die auch in index.xml vorgehalten werden (und deshalb zu Inkonsistenzen führen können): Der betreffende Cache bekommt im Memory einen Merker, dass hier eine Inkonsistenz zwischen index.xml und <cache>.xml vorliegt. Entscheidet sich die Anwenderin beim Verlassen für "Speichern", so löst das die Inkonsistenz und nichts muss passieren. Entscheidet sie sich für "Nicht Speichern", so müssen die Daten der im Memory markierten Caches aus index.xml geladen werden und in <cache>.xml abgespeichert werden. Ist vielleicht auch nicht das schnellste, vermeidet aber die Inkonsistenzen.

[/quote]
Das Problem, das dannoch bliebe wäre: Wir halten nur 50 Änderungen im RAM. Was soll passieren, wenn die 51. eingetragen wird? Soll dann etwa ein Menü aufpoppen, mit der Frage, ob die allererste Änderung gespeichert werden soll?
Nein, nein. Bei Datenbanken wird immer sofort gespeichert, so ist man es gewohnt und anders ist es auch nur schwer händelbar. Man kann höchstens noch im Ändern-Dialog abbrechen drücken. Da wäre ich auch dafür, einen entsprechenden Button einzuführen im DetailsPanel.

Gruß,
Pfeffer.

 

[MiK]

ich wollte eben dargelegt haben, dass das ein sinnvolles, alltäglich vorgehen sein kann.
Ich vermute gar, dass dadurch die von vielen offenbar geführten "Profile" mit nur Founds oder nur interessanten und noch zu machenden Caches überflüssig werden.

Für mich ist es keine vernünftige Synchronisation, wenn danach das Profil inkonsistent ist. Dann muss man sich eher über einen vernünftigeren Weg der Synchronisation Gedanken machen. Ich umgehe das Komplett, indem ich auch am PC direkt auf den Karten der SD-Karte arbeite.

Mein Founds-Profil hat übrigens einzig und allein den Grund, die anderen Profile schlank und schnell zu halten.

 

[salzkammergut]

Das Problem, das dannoch bliebe wäre: Wir halten nur 50 Änderungen im RAM. Was soll passieren, wenn die 51. eingetragen wird? Soll dann etwa ein Menü aufpoppen, mit der Frage, ob die allererste Änderung gespeichert werden soll?

Ich habe vor bei der EVE Version die Option "Änderungen sofort speichern" (o.Ä.) in den Einstellungen (nicht mehr Präferenzen ) einzubauen. Dann können vorsichtige Zeitgenossen eine (kaum merkbare) Zeitverzögerung in Kauf nehmen und die cache.xml nach jeder Änderung sofort speichern lassen. Der interne Buffer für die 50 Caches wird dann ein "write-through" Buffer.

Grüße
salzkammergut

 

[Robin888]

Ähm.. Nur mal um auf die Ausgangsfrage einzugehen:

Wieso werden Änderungen im Detailspanel (am Status) eigentlich nicht auch direkt beim Ansichtenwechsel in der <cache>.xml gespeichert?

Robin(888)

 

[pfeffer]

so ungefähr ist es seit meinem Fix ja (ok, wird erst tatsächlich beim Beenden gespeichert, von mir aus kann auch sofort in die <cache>.xml gespeichert werden.)

Zu meiner Frage zurück: kann ich den Menüpunkt "beenden ohne speichern" löschen? (denn er erzeugt Inkonsistenzen.

Gruß,
Pfeffer.

 

[MiK]

Ich finde ihn zwar beim Testen recht praktisch, da dann nicht massenweise Caches in meinem Testprofil liegen, aber für den normalen Einsatz ist er wohl überflüssig. Änderungen an den eigentlichen Daten kann man damit sowieso nicht rückgängig machen.

 

[MiK]

@Pfeffer: Willst Du das für die 1.0 noch ändern?

 

[Engywuck]

Ich hab jetzt hier mal was gebastelt, was die Inkonsistenzen aufhebt. Folgt im wesentlichen meinem weiter oben vorgestellten Konzept (http://www.geoclub.de/viewtopic.php?p=363427#p363427).
Dann würden wir eigentlich das Speichern der <cache>.xml-Dateien beim Verlassen nicht mehr benötigen. Im Gegenteil - wenn Verlassen wird, ohne zu speichern, sollten eventuell(*) bereits gespeicherte <cache>.xml-Dateien wieder restauriert werden.
(*)=jene, die nicht in sync mit index.xml sind.

Was haltet ihr davon? Bin noch nicht ganz fertig, aber fast...

Grüße,
Engywuck

 

[MiK]

Was haltet ihr davon? Bin noch nicht ganz fertig, aber fast...

Sagen wirs mal so: Wenn daran jetzt noch solche Änderungen machen, mache ich am Montag bestimmt keinen RC. Aber wenn dadurch eine bessere, stabilere 1.0 raus kommt, habe ich auch kein Problem mit einer weiteren Verzögerung.

 

[Engywuck]

Mit nem RC, der selbständig Inkonsistenzen generiert, wär ich eh nicht so zufrieden ;-)

Engywuck

 

[pfeffer]

deswegen soll auch einfach immer gespeichert werden und die Option, zu beenden ohne zu speichern verschwinden.


Gruß,
Pfeffer.

 

[Engywuck]

deswegen soll auch einfach immer gespeichert werden und die Option, zu beenden ohne zu speichern verschwinden.

Das wäre deutlich stressfreier. Wenn man die Option "Beenden ohne Speichern" konsequent weiterdenkt und fortführt, kämen ja noch so lustige Dinge dazu wie

• Entfernen von neu angelegten Wegpunkten
• Restaurieren gelöschter Wegpunkte
• Zurücknehmen weiterer Änderungen wie z.B. Notizen

Herrscht Einverständnis, dass ich den "Beenden ohne Speichern" Menüpunkt entfernen kann? Meine anderen Änderungen würden sich dann darauf beschränken, die Konsistenz über Abstürze hinweg zu retten.

Grüße,
Engywuck

 

[pfeffer]

dazu gab es ja in einem anderen Thread schon eine Diskussion. Das Ergebnis war: Beenden ohne speichern entfernen.

Gruß,
Pfeffer.

 

[salzkammergut]

Bin auch dafür das "Beenden ohne speichern" zu entfernen.

salzkammergut

 

[Engywuck]

Da ist mir noch was aufgefallen.
Das Automatische Speichern beim Beenden wird ja nur deshalb eingeführt, weil es sonst Inkonsistenzen mit den Cache-Daten geben kann. Jetzt gibt es aber noch so einige sonstige Profil-Einstellungen, die dann ebenfalls (und eigentlich grundlos) mit gespeichert werden. Ich finde es bislang sehr angenehm, dass ich z.B. den Filter ändern kann (um z.B. grad mal zu schauen, ob es neue Multis gibt, für die ich noch den Löser vorbereiten könnte), ohne ihn danach wieder zurücksetzen zu müssen.
Wollen wir auf diese Möglichkeit verzichten, oder - alternative - soll nur die Cacheliste immer gespeichert werden und der Rest auf Nachfrage? Mir würde eher letzteres zusagen - aber das braucht natürlich auch wieder ein bisschen Programmieraufwand.

Grüße,
Engywuck

 

[pfeffer]

Wir können Filter leider nicht ganz unabhängig von den neuen Wegpunkten speichern.
Beispiel:
Du hast Filter A aktiv, fügst dann einen Wegpunkt hinzu, so dass die index.xml gespeichert werden muss.
Dann änderst Du den Filter. Schließlich beendest Du CacheWolf. Wenn er nun fragt, ob er den Filter speichern soll und Du mit "nein" antwortest, dann werden die Caches dennoch in der Reihenfolge in die index.xml geschrieben, wie sie Deinem aktuellen Filter entsprechen.

Naja, ich bin nicht der Filterkenner (das ist SKG), aber ich fürchte Probleme, wenn wir nicht immer alles speichern.

Also: Filter speichern-Frage erst nach der 1.0, wäre mein Vorschlag.

Gruß,
Pfeffer.

 

[salzkammergut]

Weiter oben habe ich mich auch für die Entfernung der Funktion "Beenden" (ohne Speichern) ausgesprochen. Inzwischen komme ich wie Pfeffer zum Schluss, dass ich die "Beenden" Funktion eher so lassen würde um mal die 1.0 fertig zu stellen und in der Zwischenzeit darüber zu diskutieren wie das Speichern am Besten gelöst werden sollte.

Trotzdem einige Hintergrundinfos zum Filter:

Jeder Cache hat ein internes unsichtbares Feld "is_filtered". Wenn das wahr ist, ist er unsichtbar (=gefiltert) aber trotzdem noch in der Cacheliste vorhanden.

Dieses Feld wird für jeden Cache in der index.xml mit den Cachedaten gespeichert.

Wenn beim Speichern der index.xml ein Filter aktiv ist, wird er beim neuerlichen Einlesen wieder angewendet, d.h. jede einzelne Zeile der index.xml wird überprüft ob sie die Filterkriterien erfüllt und dargestellt werden soll. Es wird also für jeden Cache das Feld "is_filtered" neu berechnet und das gespeicherte "is_filtered" Feld ignoriert.

Wenn der Filter beim Speichern der index.xml inaktiv ist, so wird das Feld "is_filtered" verwendet um zu entscheiden ob der Cache sichtbar oder unsichtbar ist. Man kann also bei nicht aktivem Filter, einzelne Caches ausblenden (über das Filter Menü), dann Speichern und die ausgeblendeten Caches sind beim neuerlichen Öffnen des Profils noch immer unsichtbar.

Entscheidend ist also der Zustand des Filters beim Speichern der index.xml.

Gruß

salzkammergut

 

[pfeffer]

Inzwischen komme ich wie Pfeffer zum Schluss, dass ich die "Beenden" Funktion eher so lassen würde um mal die 1.0 fertig zu stellen

D.h. immer alles speichern (spätestens beim Beenden), ohne Nachfrage (also schon eine kleine Veränderung gegenüber dem aktuellen Zustand).

Gruß,
Pfeffer.