index.xml

[greiol]

<CACHE name = "Wegekreuze : Das Mülleposskreuz" owner = "Ludon" lat = "51.1299" lon = "6.833083" hidden = "2008-06-14" wayp = "GC1D7G4" status = "" type = "2" dif = "1" terrain = "1" filtered = "false" size = "Micro" online = "true" archived = "false" has_bug = "false" black = "false" owned = "false" found = "false" is_new = "false" is_log_update = "true" is_update = "false" is_HTML = "true" DNFLOGS = "0" ocCacheID = "" is_INCOMPLETE = "false" lastSyncOC = "    <CACHE name = " num_recommended = "0" num_found = "0" attributesYes = "0" attributesNo = "0" />

steht in meiner index.xml

das zweite

<CACHE name =

innerhalb von lastSyncOC irritiert mich dabei etwas. das sieht nicht so aus als würde es dorthin gehören.

der fehler taucht in allen meinen profilen bei mehreren aber nicht allen caches auf.

gepfelgt werden die profile über inkrementelle gpx importe

 

[MiK]

Das sieht so aus, als würde da in lastSyncOCirgendwie ein komischer Wert geraten zu sein. Und da Du OC nicht nutzt, ändert sich das auch nie. Ist das bei neuen Profilen bei Dir auch so? Was passiert, wenn Du mal bei OC abrufst?

 

[greiol]

falls es ausser mir keiner beobachtet hat, werde ich den unfug mal rauslöschen und hoffen, dass es nicht wieder kommt.

 

[Engywuck]

Hier scheint es sich um ein sehr ähnliches (oder das gleiche?) Problem zu handeln, welches ich schon hier beschrieben habe. Dazu folgende Fragen:

• Arbeitest Du auf dem PDA oder dem PC ?
• Wenn PDA: Liegen Deine Profile auf der Speicherkarte?
• Achte mal auf die gesammte Anzahl von Caches, die unten in der Statuszeile angezeigt werden. Wird diese Zahl kleiner, wenn Du ein Profil nur lädst, speicherst und dann nochmal lädst? (Evtl. ein paar mal hintereinander probieren.) Die Zahl sollte idealerweise immer gleich bleiben.

Grüße,
Engywuck

 

[greiol]

- sowohl als auch, wobei importe immer auf dem pc laufen
- die liegen auf einer 4 gb speicherkarte (schon ewig)
- die zahl der caches belibt konstant. es steht einfach nur unsinn in der index.xml

da cw aber die index.xml nicht als xml parst, fällt es erst mal nicht auf

 

[Kappler]

Ich habe in meiner (internen) Version ein zusätzliches Element in den CacheHolder eingebaut, in dem das Datum der letzten Aktualisierung abgelegt wird: DateLastUpdate.
Beim Ersten Versuch habe ich beim Abspeichern den selben verqueren Inhalt bekommen wie du...
Und zwar ist der Fehler beim Auslesen der index.xml entstanden, als ich eine "alte" Index-Datei (ohne den neuen Wert) wie im folgenden Codeschnipsel ohne die "if (start > 0)..." ausgelesen habe: Für den letzten Wert wurden bereits Daten des nächsten Caches ausgelesen, und der beginnt eben nunmal mit <cache name...

Sind es vielleicht sehr alte Profile, die irgendwann mal mit einer fehlerhaften CW-Version (ohne die if-Abfrage beim Einlesen, als LastSyncOC neu eingeführt wurde) bearbeitet wurden?
Und diese fehlerhaften Inhalte wurden seitdem einfach mitgeschleppt...

			start=xmlString.indexOf('"',end+1); end=xmlString.indexOf('"',start+1);
			numFoundsSinceRecommendation = Convert.toInt(xmlString.substring(start+1,end));
			recommendationScore = LogList.getScore(numRecommended, numFoundsSinceRecommendation);

			start=xmlString.indexOf('"',end+1); end=xmlString.indexOf('"',start+1);
			if (start > -1 && end > -1) {
				attributesYes = Convert.parseLong(xmlString.substring(start+1,end));

				start=xmlString.indexOf('"',end+1); end=xmlString.indexOf('"',start+1);
				if (start > -1 && end > -1)
					attributesNo = Convert.parseLong(xmlString.substring(start+1,end));
			}

			start=xmlString.indexOf('"',end+1); end=xmlString.indexOf('"',start+1);
			if (start > -1 && end > -1) {
				DateLastUpdate = xmlString.substring(start+1,end); 
				// Convert the US format to YYYY-MM-DD if necessary
				if (DateLastUpdate.indexOf('/')>-1) DateLastUpdate=DateFormat.MDY2YMD(DateLastUpdate);
			}

Auf jeden Fall dürfte es nichts schaden, wenn diese fehlerhaften Inhalte gelöscht werden, und sie sollten anschließend auch nicht mehr neu auftauchen...

@dev: Eventuell wäre es in Zukunft sinnvoll, das Parsen der index.xml flexibler zu gestalten, um so etwas zu vermeiden: Wenn jemand lange nicht die CW-Version updatet und beispielsweise ein Profil hat, in dem LastSyncOC oder numFoundsSinceRecommendation noch nicht vorkommt, dann tritt dort dieser Fehler wieder auf...

 

[greiol]

das waren 0.9er profile. die allerdings valide (xml) waren bis sie mit 1.0 verarbeitet wurden.
ich habe es erst gemerkt als der xml parser heute ausgestiegen ist. und die änderung war der sprung von 0.9n4 auf 1.0.

die RCs hatte ich vorher immer mit eigenen profilen getestet.

hat sich das format der index.xml von 0.9 zu 1.0 geändert? falls ja, könnte man in die profile eine versionsinfo einbauen und in cw eine abfrage, damit er auch nur die profile liest die er sauber verarbeiten kann? (wir haben ja jetzt ne 1.0, da kann man wieder nach neuen features fragen )

nach der manuellen bereinigung ist der fehler auch nach einem import einer aktuellen pq nicht aufgetreten. ich werde jetzt mal den rest putzen.

sollte man evtl. in der ankündigung für die neue version darauf hinweisen, dass eien migration von 0.9 probleme machen kann?

 

[Kappler]

hat sich das format der index.xml von 0.9 zu 1.0 geändert? falls

Ich nehme an, dass irgendwann mal die Werte
LastSyncOC, num_Recommended, num_found, AttributeYes und AttributeNo
nachträglich in Cw eingebaut worden sind.
Und wenn dann in irgendeiner Zwischenversion nicht sauber abgefragt wurde, ob im gerade eingelesenen Profil diese Werte überhaupt enthalten sind, dann könnte das reingerutscht sein.
Und anschließend, da diese Werte bei dir nie benutzt worden sind, ist der falsche Inhalt immer sauber abgespeichert und wieder eingelesen worden.

Von daher wäre wirklich zu überlegen, wie man so etwas in Zukunft vermeiden könnte.
Ich könnte mir schon vorstellen, dass mit neuen Features auch neue Einträge in den CacheHolder übernommen werden.
Und wahrscheinlich gibt es auch immer noch Nutzer, die irgendwelche Uralt-Versionen benutzen und somit auch entsprechend alte Profile mit fehlenden Variablen mitschleppen...

 

[greiol]

es wird alle erwischen die noch auf 0.9 sind.

solange sie nur cw benutzen wird es ihnen nicht auffallen. erst wenn man die index.xml nach der umstellung anschaut wird man sehen, dass der komische kram drin steht, der unter 0.9 nicht drin stand.

evtl. könnte man <CACHELIST> die revision der cw version mitgeben die die index.xml geschrieben hat. so kann man dann auch abprüfen ob es "noch klappt" oder schief gehen wird.

für anwender wäre es dann praktisch zu wissen mit welcher version die jeweilige konvertierung klappt, bzw. ob es einen externen konverter gibt.

 

[MiK]

es wird alle erwischen die noch auf 0.9 sind.

Bist Du Dir da sicher? Kappler meint ja, dass es mit der aktuellen Version abgefangen wird und nur in einer Zwischenversion dieser Fehler reingerutscht ist. Hast Du denn ein 0.9er Profil, dass Du mit Zwischenversionen nicht genutzt hast?

 

[greiol]

aaalso

die profile um die es geht wurden zuletzt am montag mit 0.9n4 gespeichert. da ich keine spider funktionen genutzt habe, überwiegend mit anderer kartensoftware arbeite und keine downloads von oc mache, war die 0.9n4 "good enough".

weil mir ein paar sachen im cw fehlen, die ich gerne wollte habe ich mir ein paar tools gebaut die die index.xml als xml einlesen und parsen. daraus generiere ich mir dann meine exporte.

ich habe mir zwischendurch zwar immer mal wieder eine zwischenversion angeschaut, aber die habe ich nie auf meine "produktionsdaten" schreiben lassen. bestenfalls mal eine kopie, meistens eigene profile, die einfach enie aktuelle pq bekommen haben.

auch rc12 und rc2 durften zunächst nicht auf die "produktion" schreiben. allerdings ist mir die parallelinstallation nach einiger zeit auf den zeiger gegangen, weil die liste der gefundenen caches so auseinander lief. vor allem weil ich letztes wochenende mal den "finalen" probelauf gemacht hatte und mal nur den rc2 mitgenommen hatte. auch die exporte mit meinen tools haben aus dem stand mit dem rc2 funktioniert.

weil der lauf mit dem rc2 für mich ausgesprochen zufriedenstellend war, habe ich gestern die vorhandenen profile aus dem datenverzeichnis der 0.9er in das vom rc2 kopiert, die fundlisten endlich abgeglichen und die akteullen pqs reingeladen.

heute wollte ich mir wieder meine exporte ziehen und bekam die meldung, dass die index.xml kein valides xml sein. und dann begann der fred.

 

[greiol]

ich muss mal sehen wo die 0.9er ist. das müsste sich ja auch mit einem test validieren lassen. 0.9 installieren, alte pq rein, rüber nach 1.0 kopieren, neue pq rein und wenn es dann hakt, wissen wir es.
aber jetzt ruft erst mal der grill.

 

[Kappler]

Es wird mit der aktuellen Version alles abgefangen, was nach den OC-Variablen im CacheHolder steht.

Ich kenne die historische Entwicklung nicht, aber wenn die OC-Variablen erst nachträglich eingebaut wurden und noch Profile aus der Zeit davor im Umlauf sind, dann könnten hier Probleme entstehen...

Alle Profile, die nicht alle der folgenden Variablen enthalten, werden Schwierigkeiten machen:

is_incomplete;
is_black;
addiWpts;
mainCache;
is_new;
is_flaged;
is_Checked;
ocCacheID;
noFindLogs;
has_bug;
is_HTML;
this.sort=ch.sort;
lastSyncOC;

Bei den restlichen 2 Variablen wird beim Einlesen geprüft, ob sie enthalten sind:

attributesYes;
thattributesNo;

Wenn jetzt jemand noch weiß, wann die einzelnen Werte eingebaut wurden, dann kann auch gesagt werden, vor welcher Profil-Version Probleme zu erwarten sind...

 

[MiK]

Ich konnte es gerade mit einem mit 0.9 angelegten Profil nachvollziehen.

Auf jeden Fall ist es dadurch erstmal kein valides XML mehr. Aber konnte jemand negative Auswirkungen auf das Verhalten von CW selbst beobachten?

 

[greiol]

cachewolf selber kommt damit zurecht, da er an der stelle ja keinen xml parsr (mehr) benutzt.

vermutlich sollte man umsteigern aber einen weg mitgeben, wie sie ihre profile aufräumen können. sonst knallt es mit den einträgen irgendwann später, wenn der cw code sich mal wirklich anschaut was er da einliest und dann ist das alles noch länger her wenn man versucht herauszufinden was das für ein fehler ist. einmal suchen und ersetzen löst das problem ja recht gut.

 

[Kappler]

Ein negatives Verhalten wird sich wohl erst dann ergeben, wenn im obigen Beispiel die Variable LastSyncOC ausgewertet werden soll: Dann wird ein falscher Wert verwendet...

Andererseits wird beim ersten mal Schreiben der index.xml mit korrekten Daten, die während des CW-Laufs ermittelt wurden, wieder etwas korrektes zurückgeschrieben...

Ich denke es wäre am sinnvollsten, in den nächsten Bugfix bzw. die nächste Version "heimlich, still und leise" eine Bereinigungsfunktion einzubauen, die testet, ob in den einzelnen Variablen der index.xml etwas vernünftiges enthalten ist und im Bedarfsfall ausputzt...

Dies müsste nur einmalig ausgeführt werden, da nach dem nächsten Speichern die Default-Werte zurückgeschrieben würden. Der Vollzug dieser Prüfung könnte mit in der index.xml gespeichert werden, so dass wirklich nur einmal je Profil geprüft würde...

Für die Zukunft wäre dann auch eine Prüfung beim Einlesen der index.xml notwendig, ob die jeweilige Variable vorhanden ist. Wobei das allerdings dan Performance beim Einlesen kosten dürfte...

 

[greiol]

Dies müsste nur einmalig ausgeführt werden,
...
Wobei das allerdings dan Performance beim Einlesen kosten dürfte...

das schreit doch geradezu nach einem "migrationshilfetool" welches einmalig anzuwenden ist.
oder es könnte in der verwaltung verschwinden, wie bei "index neu erstellen".

 

[Kappler]

Das "migrationshilfetool" ist bestimmt für geübte User die Beste Lösung, aber für die anderen dürfte das eher für Verwirrung sorgen und den Supportaufwand erhöhen: Ich sehe schon zig Threads zum Thema "Ich habe bisher Version x, was muss ich jetzt tun um Version y einsetzen zu können?"

Bei weiterem Nachdenken glaube ich auch nicht, dass bei jedem Einlesen auf die Korrektheit geprüft werden müsste. Eine Versionsinformation im Profil, wie von dir weiter oben vorgeschlagen, dürfte genügen, um eventuell, bei Abweichungen, einmalig eine "Migrationsfunktion" zur Bereinigung auszuführen.
Nach dem nächsten Speichern stimmt dann ja wieder alles...

 

[greiol]

Eine Versionsinformation im Profil, wie von dir weiter oben vorgeschlagen, dürfte genügen, um eventuell, bei Abweichungen, einmalig eine "Migrationsfunktion" zur Bereinigung auszuführen.
Nach dem nächsten Speichern stimmt dann ja wieder alles...

das könnte man dann ggf. auch für "migrationen" der einzelnen cache.xml verwenden falls sich da mal etwas tut.

 

[Engywuck]

Einfacher wäre es eigentlich, neue Informationen so in die Dateien einzubauen, dass die bisherige Datenstruktur nicht gestört wird. Das kann man mit XML ja eigentlich machen.
Vielleicht liegt das Problem auch daran, dass der Wolf eventuell xml-Dateien schreibt, aber bei weitem keine xml-Dateien liest.

E.