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

[Engywuck]

Moin moin,
ich habe mich einmal um den nächsten großen Punkt gekümmert, der mich im CacheWolf-Datenmodell schon länger stört, und zwar die Klassen CacheHolder/CacheHolderDetail. Dieses Pärchen fand ich immer sehr verwirrend. Aufgrund der Ableitung CacheHolderDetail extends CacheHolder können die Hauptinformationen in beiden Objekten vorkommen - wann was zu verwenden ist, und was nun gilt, ist nicht immer so ganz einsichtig. Innerhalb des Cachewolfs wird mal das eine, mal das andere Objekt instanziert - alles sehr komisch.
Hier habe ich nun mal was aufgeräumt. Die wichtigsten Änderungen sind:

• Die Vererbung CacheHolderDetail -> CacheHolder ist aufgehoben. Es handelt sich nun um getrennte Objekte.
• CacheHolder speichert nur noch die Kopfdaten, die für alle Caches immer zur Verfügung stehen sollten, CacheHolderDetail speichert die Detailinformationen, die bei Bedarf aus der Cache.xml-Datei ausgelesen werden. Zwischen den Objekten gibt es 1:1-Referenzen.
• Auf die Eigenschaft details des Objekts CacheHolder wird nur noch per Getter zugegriffen.
• CacheHolder ist das einzige Objekt, das CacheHolderDetail instanziiert, und zwar genau dann, wenn es per entsprechendem Getter angefordert wird.
• Die Liste CachesWithLoadedDetails speichert nun Wegpunkte (String) statt Objekte, um weniger Möglichkeiten für Speicherlecks zu haben.

Wenn man jetzt ein Cache-Objekt verwenden (oder erzeugen) möchte, so kann man das tun, in dem man CacheHolder nutzt. Wenn man die Details verwenden möchte, kann man auf sie einfach per Getter zugreifen, ohne sich um Weiteres kümmern zu müssen. Das ganze interne Handling, das dafür notwendig ist, wird transparent von den Klassen CacheHolder und CacheHolderDetails übernommen. Kein hässliches detailsAdded mehr, welches nach jedem externen Erzeugen von Details aufgerufen werden muss...
Natürlich hat diese Änderung einigen Einfluß auf diverse Klassen, und es ist nicht ausgeschlossen, dass noch der ein- oder andere Fehler drin ist. Beim mir läuft das allerdings alles tadellos und ich habe - denke ich - alles mal ausprobiert. Da wir zur Zeit auch nicht vor einem neuen Release stehen, ist die Zeit günstig, auch mal tiefere Eingriffe vornehmen zu können.
Ich hänge die Änderungen erstmal als Patch an. Wer mag, kann sie sich ja erstmal angucken. Falls es keine sinnvoll motivierten Proteste gibt, würde ich die Sachen dann in den nächsten Tagen committen.

Gruß,
E.

 

[pfeffer]

ja, endlich macht das mal jemand!

ich habe jetzt nicht alles getestet, aber einen mini-Verbesserungsvorschlag: in public CacheHolderDetail getCacheDetails(boolean maybenew, boolean alarmuser)

if (details != null && !cachesWithLoadedDetails.contains(this.getWayPoint())
					&& !this.getWayPoint().equals(CacheHolder.EMPTY)) {

müsste sich das contains(..) sparen lassen, oder?
bzw. glaube ich, man sollte bevor man die Cache.xml einliest prüfen, ob man sie schonmal eingelesen hat und gegebenenfalls das Objekt zurückgeben.

EDIT: eigentlich ist die Prüfung überflüssig, weil wenn details==null, dann sollte es auch keine geben. Allerdings könnte sich eine Methode eine Kopie des CacheHolders angelegt haben, die Details geladen haben und nun eine andere nach den Details fragen. In diesem Fall wäre es schon sinnvoll nach den Details zu suchen. Allerdings weiß ich nicht, ob eine Methode so etwas macht und ob man das verbieten kann, denn Kopien von den gleichen Daten zu haben, ist selten gut

Gruß,
Pfeffer.

 

[Engywuck]

in public CacheHolderDetail getCacheDetails(boolean maybenew, boolean alarmuser)

if (details != null && !cachesWithLoadedDetails.contains(this.getWayPoint())
					&& !this.getWayPoint().equals(CacheHolder.EMPTY)) {

müsste sich das contains(..) sparen lassen, oder?

Fast, ja. Das Problem sind hier "temporär erzeugte Hilfs-CacheHolder-Objekte", die beim Aktualisieren eines exitierenden Caches gebraucht werden, um die neuen Daten aufzunehmen. Am Ende des spiderns wird der "Originalcache" dann geupdatet. Dieser Hilfscache kann dann durchaus den gleichen Wegpunkt haben wie der Hauptcache, aber in die Liste muss er nicht, wenn es da schon einen gibt. (siehe SpiderGC.spiderSingle() )Er wird ja nachher sowieso vom GarbageCollector abgeräumt.

Als Bemerkung noch: Diverses ist etwas "defensiv" programmiert, damit es mit existierendem Code funktioniert. Ich wollte da nicht zuuuu viele Baustellen aufmachen. Das wird man in Zukunft noch optimieren können...

Gruß,
E.

 

[pfeffer]

mein Edit hat sich wohl mit Deiner Antwort überschnitten.

ahh - verstehe. vielleicht machst Du dann da einen Kommentar dran, dass das nur notwendig ist, weil und solange spiderGC auf diese seltsame Weise arbeitet und die cache.xml direkt ändert.

Das wurde damals übrigens wohl so gemacht, weil es irgendwo ein Speicher-Leck gab (dessen Ursache wir leider nicht kurzfristig ausfindig machen konnten). Wenn man das irgendwie anders weg bekommt, wäre das schon schön.

Gruß,
Pfeffer.

 

[salzkammergut]

@Engywuck: Super dass Du das mal angepackt hast - war auch mir schon lange ein Dorn im Auge.

Grüße
skg

 

[Engywuck]

Aufgrund der allgemeinen Zustimmung habe ich die Änderungen commited.
Weitere Optimierungen folgen...

Gruß,
E.

 

[greiol]

daumen hoch

 

[MiK]

Ich habe gerade festgestellt, dass der Hauptwegpunkt nicht mehr markiert ist, nachdem man ihn aktualisiert hat. Kann das mit dieser Änderung zusammenhängen?

 

[Engywuck]

Was meinst Du jetzt mit "markiert" ? Das Häkchen?

 

[MiK]

Ja. Die dazugehörigen Addis haben danach noch das Häkchen. Alle vorher angehakten Hauptwegpunkte haben nach dem Aktualisieren ihre Haken verloren.

 

[Engywuck]

Habs auch grad gesehen und gefixed.

Gruß,
E.

 

[MiK]

Danke, funktioniert.

 

[jukker]

Hallo zusammen, ich mache mit diesem Posting mal meinen Einstand ;-)

Seit Revision 1748 besteht folgendes Problem:
- Ich markiere einen Multicache, der aus mehreren Wegpunkten besteht
- Ich lasse diesen Cache aktualisieren

Als Ergebnis sind anschliessend alle Wegpunkte dieses Caches, die gesetzte Koordinaten haben, mit rotem Punkt (Update in Cache-Beschreibung) versehen. Alle Wegpunkte ohne Koordinaten haben keinen roten Punkt gesetzt.
Das passiert übrigens immer, auch wenn es gar keine Updates in der Cache-Beschreibung gegeben hat.

Bis Revision 1747 funktionierte das noch.

 

[Engywuck]

Wie war das Verhalten denn vorher?

Gruß,
E.

 

[jukker]

Wie war das Verhalten denn vorher?

Wenn es kein Update in der Cache-Beschreibung gab, wurde auch kein roter Punkt angezeigt. Die Liste sah nach dem Aktualisieren also genauso aus wie vorher.

Wenn es ein Update in der Cache-Beschreibung gab, bin ich mir nicht sicher (lässt sich schwer testen). Entweder es wurde nur der erste Wegpunkt mit dem roten Punkt versehen oder alle.

Seit Revision 1748 wird jedenfalls IMMER beim Aktualisieren an alle Wegpunkte mit gesetzten Koordinaten der rote Punkt gesetzt und bei allen anderen nicht.

 

[MiK]

Zu den anderen Punktfarben: Über->Legende

 

[jukker]

Wenn man in CacheHolder.java die folgende Zeile auskommentiert:

	public void setLatLon(String latLon) {
		latLon=latLon.trim();
//		if (!latLon.equals(LatLon.trim())) setUpdated(true);
		LatLon = latLon;
		pos.set(latLon);
	}

meint Cachewolf nicht mehr, dass es Updates in der Cache-Beschreibung gegeben hätte (keine roten Punkte).

Offenbar meint Cachewolf also, die neu geladenen und die alten Koordinaten wären verschieden, obwohl das definitiv nicht so ist. Irgendwo ist da der Wurm drin, ich seh ihn nur nicht.

 

[Engywuck]

Wie sollten sich die Punkte eigentlich beim Aktualisieren verhalten? Wenn sich nichts neues ergeben hat, soll der Punkt verschwinden? Wie ist das bei anderen Aktionen (gpx-Import, z.B.)?

Gruß,
E.

 

[Kappler]

...Wenn sich nichts neues ergeben hat, soll der Punkt verschwinden?...

So würde ich das sehen und so ist es auch beim GPX-Import...

 

[Engywuck]

Wie sollen sich denn die Auszeichnung bestehender Caches ändern, wenn ich spidere (wo ja nur neue hinzukommen)? Was wird aus
- roten (= Update in Cache)
- gelben (= neuer Cache)
- blauen (= neue Logs)
Markierungen?

Gruß,
E.