[DEV] Änderungen im Datenmodell: CacheHolder/...Details

[MiK]

Ich bin dafür, dass diese alle zurück gesetzt werden. Die Punkte sollen nur den letzten Vorgang darstellen. Beim Spidern kann es aber durchaus mittlerweile auch Aktualisierungen geben. Bzw. wurde früher schon der Status umgestellt, wenn eine Änderung festgestellt wurde. Jetzt können diese Caches bei Bedarf auch aktualisiert werden.

 

[jukker]

Ich habe gerade mit einer Version vor der CacheHolder-Änderung getestet:
- einen GC-Cache, der neue Logs hat, aktualisiert -> blauer Punkt
- anschliessend spidern
Ergebnis: Der blaue Punkt ist immer noch da.

Ich meine aber, dass Änderungen wie nicht suchbar, archiviert oder selbst gefunden beim Spidern aktualisiert wurden. Dies konnte ich allerdings nicht testen.

 

[Engywuck]

Bezüglich spidern bei GC.com habe ich jetzt mal was korrigiert (Build 1771). Opencaching und GPX-Import muss ich mir noch angucken.

Gruß,
E.

 

[Kappler]

Beim GPX-Import sollte aber beachtet werden, dass es möglich ist, mehrere GPX-Dateien in einem Rutsch zu importieren.
Hier sollte nicht vor jeder einzelnen Datei pauschal alles zurückgesetzt werden, da sonst die Änderungen, die durch das Einlesen der ersten Dateien hinzukommen, verloren gehen würden...
Besser nur einmal vor dem Einlesen der ersten Datei zurücksetzen.

 

[Engywuck]

Mehrere? Wie geht denn das? (Ich kenn mich mit dem GPX-Zeugs nicht so aus...)

Gruß,
E.

 

[jukker]

Bezüglich spidern bei GC.com habe ich jetzt mal was korrigiert (Build 1771). Opencaching und GPX-Import muss ich mir noch angucken.

Mit Build 1773 hat bisher alles, was ich getestet habe, so wie beschrieben funktioniert. Vielen Dank dafür.

So richtig rund und intuitiv ist das aber nicht, wobei das nichts mit dieser Änderung zu tun hat, das war schon immer so. Eine typischer Praxisfall dürfte die Umkreissuche sein. Man möchte alle Caches um einen Punkt finden und diese Liste dann natürlich auch aktuell halten. Ich unterscheide hier mal drei Fälle:

Fall 1:
In der Liste befinden sich ausschliesslich OC-Caches. In diesem Fall werden über "Download von opencaching.de" neue Caches hinzugefügt und schon vorhandene inkl. Logs aktualisiert. Perfekt.

Fall 2:
In der Liste befinden sich ausschliesslich GC-Caches. Hier muss man schon 2 Schritte durchführen. Zuerst muss man alle vorhandenen markieren und dann aktualisieren und schliesslich muss man auch noch spidern, um neue Caches zuzufügen.
Das Problem ist nun, dass beim zweiten Schritt Informationen, die beim ersten ermittelt wurden (neue Logs etc.) verlorengehen (zumindest seit den letzten Änderungen).

Fall 3:
In der Liste befinden sich sowohl OC- als auch GC-Caches. Hier muss man drei Schritte durchführen, um die komplette Liste aktuell zu bekommen. Auch hier werden bei jedem neuen Schritt Informationen des vorhergehenden gelöscht.

Falls das alles ganz anders viel einfacher gehen sollte, korrigiert mich.

Dies soll keine Kritik sein, ich persönlich kann mit dem jetzigen Stand gut leben. Ich wollte hiermit nur einen Denkanstoss geben. Vielleicht ergibt sich ja aus der Diskussion eine viel bessere Lösung.

 

[Engywuck]

Da hast Du natürlich recht. Das Problem ist, dass man natürlich automatisiert nicht gut entscheiden kann, wann eine Aktualisierung nur eine "Folgeaktualisierung" ist, die man benötigt, um sein Profil aktuell zu halten, weil man mit einer - wie von Dir beschrieben - nicht auskommt (wenn man in seinem Profil um mehr als ein Zentrum spidert, hat man das gleiche Problem), oder wann es sich um einen neuen Aktualisierungslauf handelt und man die existierenden Statusse (eigentlich: Status) zuvor verwerfen möchte.
Vielleicht wäre es eine Idee, wenn die Statusse nur noch manuell über das Kontextmenü über einen eigenen Befehl gelöscht werden? Dann könnte man so lange sammeln, wie man Lust hat und zurücksetzen, wenn man es für richtig hält.

Gruß,
E.

 

[Kappler]

Mehrere? Wie geht denn das?...

Im Datei-Auswahldialog für die GPXe einfach (mit Shift oder Strg) mehrere GPX-Dateien auswählen. Die werden dann nacheinander eingelesen...

...Vielleicht wäre es eine Idee, wenn die Statusse nur noch manuell über das Kontextmenü über einen eigenen Befehl gelöscht werden? Dann könnte man so lange sammeln, wie man Lust hat und zurücksetzen, wenn man es für richtig hält.

Beim genaueren Nachdenken scheint mir das auch eine gute Idee.
Mit dem derzeitigen (neuen) Verhalten hätte ich nämlich ein Problem:
Beim Neuerstellen eines Profils (z.B. Nordschweden) lasse ich mir eine größere Anzahl PQs mit den gewünschten Kriterien schicken und lese die ein.
Um nun alle Informationen zu haben (Attribute, Bilder, Logs...) möchte ich diese noch alle aktualisieren. Da es jedoch sehr viele sind (> 2000) will ich dies selbstverständlich nicht in einem Aufwasch erledigen, sondern innerhalb mehrere Wochen.
Zur Unterscheidung, welche ich noch nicht aktualisiert habe, hat mir hierzu bisher der gelbe Punkt gedient: gelber Punkt - noch nicht aktualisiert; roter Punkt - schon aktualisiert.
Mit der derzeitigen neuen Logik funktioniert das aber nicht mehr, da jetzt bereits nach dem ersten Aktualisieren alle Markierungen zurückgesetzt werden.

Aus meiner Sicht daher: Entweder manuell oder nur diejenigen Caches zurücksetzen, die im aktuellen Schritt (GPX einlesen oder aktualisieren der markierten) tatsächlich irgendwie behandelt wurden. Bei den anderen die Markierung stehen lassen, wie sie war...
Wie das beim Umkreis-Spidern sein sollte, kann ich nicht sagen, da ich diese Funktion eigentlich nie nutze.

 

[MiK]

OK, beim aktualisieren von markierten Caches, sollte nur der Status von diesen zurück gesetzt. Beim Spidern kann man es erst mal für alle machen. Später kann man das mal intelligenter machen. Es wird ja jetzt schon erfasst, welche Caches erfasst werden sollten. Das ist aber etwas schwierig, weil die Abstandsberechnungen von CW und GC nicht immer 100% überein stimmen.

Beim GPX/OC-Import würde es wohl auch genügen, nur die Caches zurückzusetzen, die angefasst werden.

 

[pfeffer]

[*] Die Liste CachesWithLoadedDetails speichert nun Wegpunkte (String) statt Objekte, um weniger Möglichkeiten für Speicherlecks zu haben.[/list]

Gab es da Speicherlecks?
Falls ja dürften die nicht allzu groß gewesen sein, schließlich ist die Anzahl Objekte in CachesWithLoadedDetails begrenzt.
Wieso sollten dadurch Speicherlecks überhaupt entstehen?

Ich muss das rückgängig machen, denn so funktioniert der Import der download von Opencaching nicht mehr. In der XML werden die Log-Einträge u.ä. nicht per Wegpunktnamen den Caches zugeorndet, sondern per CacheID. Dies hat zur Folge, dass der Wegpunkt beim Erzeugen nicht bekannt ist und damit die neuen Details nicht in der Liste der geladenen Details aufgenommen werden können.

Irgendwelche Einwände?

Gruß,
Pfeffer.

 

[Engywuck]

[*] Die Liste CachesWithLoadedDetails speichert nun Wegpunkte (String) statt Objekte, um weniger Möglichkeiten für Speicherlecks zu haben.[/list]

Gab es da Speicherlecks?
Falls ja dürften die nicht allzu groß gewesen sein, schließlich ist die Anzahl Objekte in CachesWithLoadedDetails begrenzt.
Wieso sollten dadurch Speicherlecks überhaupt entstehen?

Ob es Speicherlecks gab, weiss ich nicht. Aber es ist potentiell gefährlich, in einer Liste Objektreferenzen festzuhalten, wenn man nicht absolut sicher ist, dass man diese Objektreferenzen auch wieder entfernt, wenn das Objekt an allen anderen Stellen nicht mehr verwendet - eine der wenigen Möglichkeiten in Java, Speicherlecks zu erzeugen.
Da diese Liste nur eine "Merkliste" ist, welche Caches geladene Details haben, habe ich hier eben nicht die Objekte als Identifier genommen, sondern die Wegpunkte als Strings. Damit kann das Cacheholder-Objekt nicht ungenutzterweise da noch rumstehen.

Wieso Du in dieser Liste jetzt die tatsächlichen Objekte benötigst, hab ich Deiner Erläuterung noch nicht entnehmen können - aber vielleicht sollte ich mir dazu erstmal den Code angucken ;-)

Gruß,
E.

(frisch aus dem Urlaub)

 

[pfeffer]

ich habe irgendwie Zweifel, ob Deine Variante gegen Speicherlecks helfen würde: schließlich werden die Referenzen statt dessen in der Hashtable gespeichert (ää oder bring ich da jetzt was durcheinander? - da speicherst Du nur Referenzen auf die CacheHolder, nicht auf die Details?).

Ich habe eigentlich keine Sorge, dass an dieser Stelle Speicherlecks entstehen. Es werden halt bis zu 50 CacheDetails geladen - und das sollen sie auch. Wenn es mehr werden, werden welche wieder entfernt.
Da kann also eigentlich gar kein Leck entstehen.

Er soll sich ja gerade die CacheDetails merken (auch, wenn sie gerade nirgendwo anders gebraucht werden), damit sie beim nächsten Gebrauch nicht wieder von der Platte gelesen werden müssen.

Der Zugriff direkt auf die Referenz ist natürlich schneller. Aber der Grund meiner Änderung war, dass der Import von neuen Caches über den Download von Opencaching nach Deiner Änderung nicht mehr funktioniert hatte (die <cache>.xml wurden nicht erzeugt).
Warum Deine Änderung dazu geführt hatte, dass es dieses Problem gab: Bei Opencaching sind die Beschreibungen und die Logs und die Bilder usw. getrennt von den Wegpunkten in einer .xml. Es werden erst alle Wegpunkte eingelesen, danach die Beschreibungen, wobei die Beschreibungen eine OpencachingID des zugehörigen Wegpunktes enthalten, die nicht der normale Wegpunktname (nicht "OCxxxx" ist. Deswegen funktionierte das Zusammenbinden der Wegbeschreibung mit den Wegpunkten nicht mehr.

Gruß,
Pfeffer.

Gruß,
Pfeffer.

 

[Engywuck]

Ich muss das rückgängig machen, denn so funktioniert der Import der download von Opencaching nicht mehr.

Hab mir mal Deine Änderungen angeguckt. Das von Dir geschilderte Problem kann damit aber nicht zusammenhängen (bzw. besser: darf nicht ;-) ). Kannst Du kurz beschreiben, was ich machen muss, damit ich das Problem reproduzieren kann? (In der alten Fassung mit Strings statt Objekten in der Auflistung)

Gruß,
E.

 

[Engywuck]

Ich hab jetzt mal in einem neuen leeren Profil einen Download von opencaching durchgeführt, und zwar mit Rev. 2065 (die sollte den Fehler noch haben). Ich habe keine Unauffälligkeiten feststellen können. Kann mir mal jemand erklären, worin der Fehler liegen soll? (Bin kein opencaching-Nutzer, daher kenn ich mich da nicht so aus...)

Gruß,
E.

 

[Engywuck]

Ich hab jetzt mal in einem neuen leeren Profil einen Download von opencaching durchgeführt, und zwar mit Rev. 2065 (die sollte den Fehler noch haben). Ich habe keine Unauffälligkeiten feststellen können. Kann mir mal jemand erklären, worin der Fehler liegen soll? (Bin kein opencaching-Nutzer, daher kenn ich mich da nicht so aus...)

Gruß,
E.

 

[pfeffer]

nach dem Download von opencaching (in einem neuen Profil) musst Du beenden und neu starten. Dann ist die Liste der Caches zwar da, aber nicht mehr die Cache-Beschreibung. Sie fehlt dann bei allen Caches. Wenn man nun ein 2.mal runterlädt, dann merkt er sich auch die Beschreibung.

Gruß,
Pfeffer.

 

[Engywuck]

Ich habe den Code jetzt so weit, dass das runterladen von OC klappt, ohne dass ich mir Objektreferenzen merken muss.
Was mich aber noch verwundert (und das Verhalten ist im aktuellen Build genauso): Wenn ich die Cachebeschreibung eines OC-Caches in der xml-Datei manuell verändere, dann das Profil lade und dann diesen Cache aktualisiere, dann wird meine Änderung nicht mit dem "offiziellen" Text überschrieben. Soll das so sein? Oder ist das noch ein eigener Fehler?

Edit:
Grad rausgefunden: Es gibt da ja noch das LastSyncDate. Wenn ich auch dies für den Cache manuell zurücksetze, dann passiert auch was, aber was interessantes: Bei HTML-Beschreibungen wird die aktualisierte Beschreibung drangehängt. (Quelle: OCXMLImporter.java, Zeile 605)
Mir kommt das seltsam vor - oder hab ich nur wieder was übersehen?

Gruß,
E.

 

[pfeffer]

und was soll das?
Warum nicht direkte Objektreferenzen?
Das geht schneller ich ich denke, es spricht nichts dagegen.

Gruß,
Pfeffer.

 

[MiK]

Vorweg: Ich kenn den Code nicht. Weder die Pfeffer- noch die Engywuck-Version.

Ich frage mich: Wenn die Objektreferenzen nicht gespeichert werden, wie wird dann sichergestellt, dass die Daten gecacht werden?

 

[Engywuck]

Weil Objektreferenzen keine saubere Programmierung sind. Es gibt einige Stellen, wo ein Cacheholder-Objekt erzeugt wird, ohne dass es nachher Eingang in die CacheDB findet, weil es nur als Container für zu aktualisierende Daten dient. Ohne Objektreferenz kann der GC das Objekt abräumen und es stört nicht weiter. Mit Objektreferenz bleibt das Objekt erstmal leben, und das ist doof.
An dieser Stelle hast Du nur deshalb kein Speicherleck, weil das Objekt spätestens durch die "max-50-Caches"-Regel rausfliegt. Aber zum einen ist das eben keine saubere Programmierung, zum andern wird dadurch der Platz für die Caches belegt, die man damit eigentlich im Speicher halten möchte.
Zusätzlich: Durch diesen Mechanismus lebt das Objekt deutlich länger als nötig, und dies hat evtl. Konsequenzen:

Dank der HotSpot-Technologie, die seit Java 1.3 fester Bestandteil des Java SDK ist, geschieht das Anlegen von Objekten unter der Java VM von Sun sehr schnell. HotSpot verwendet einen generationenorientierten GC, der ausnutzt, dass zwei Gruppen von Objekten mit deutlich unterschiedlicher Lebensdauer existieren. Die meisten Objekte sterben sehr jung, die wenigen überlebenden Objekte werden hingegen sehr alt. Die Strategie dabei ist, dass Objekte im »Kindergarten« erzeugt werden, der sehr oft nach toten Objekten durchsucht wird und in der Größe beschränkt ist. Überlebende Objekte kommen nach einiger Zeit aus dem Kindergarten in eine andere Generation, die nur selten vom GC durchsucht wird.

Das Argument, dass der Stringvergleich schneller ist als der Objektvergleich, kann ich nicht gelten lassen. Mir scheint die Schnelligkeit mittlerweile zu einem Totschlagargument zu verkommen, mit dem man jede Art von Code legetimieren kann, wenn er denn nur prinzipiell ein Nanosekündchen schneller ist.

@MiK:
Es geht nur darum, sich zu merken, welche Caches geladene Details haben, um sie beim Speichern gegebenenfalls abspeichern zu können und um zu wissen, welche Details man ggf. entladen will. Dazu reicht (i.a.) der Wegpunktname aus. Die Objektreferenz wird dazu nicht benötigt, die haben wir nämlich in der CacheDB. Und bei den Caches, die nicht in der CacheDB sind, brauchen wir die Referenz auch nirgendwo anders.

Gruß,
E.