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

[pfeffer]

sorry, aber Objektorientierung lebt von Objektreferenzen.
Und ja: diese Routine wird beim OC-Download-Import sehr oft gebraucht. Bei jedem Wegpunkt, bei jeder Cachebeschreibung, bei jeden Bild und vor allem bei jedem Log.
Und ja genau: Sinn ist, die bereits geladenen CacheDetails länger im Speicher zu halten und nicht bei jeden Log erneut von der Platte lesen zu müssen.

Ich sehe also nicht, was für Deine Variante, die Referenzen über (zu suchende!) Strings herzustellen für Vorteile haben soll - in dieser konkreten Situation.

An irgendeiner anderen Stelle, bei der andere Bedingungen gelten, magst Du schon recht haben.

Gruß,
Pfeffer.

 

[MiK]

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.

Wenn wir alle "unsauberen" Stellen in CW durch saubereren Code ersetzten und dieser dann nur etwas langsamer ist, dann haben wir am Ende einen CW, den keiner mehr benutzen möchte. Wir haben doch jetzt schon an vielen Stellen Probleme damit, dass CW zu lahm ist. Sauberkeit des Codes als Totschlagargument, möchte ich nicht akzeptieren. Man muss dadurch auch funktional etwas erreichen.

 

[Engywuck]

Ok, ich werde nichts commiten. Aber meine Motivation, hier mitzuprogrammieren, schwindet mehr und mehr.

Gruß,
E.

@MiK: Du darfst auch gerne alle getter- und setter-Methoden wieder ausbauen. Der direkte zugriff auf die Felder ist sicher schneller.

 

[MiK]

Ok, ich werde nichts commiten. Aber meine Motivation, hier mitzuprogrammieren, schwindet mehr und mehr.

Ich weiß nicht so recht, ob Du den Sinn dieses Mechanismuss verstanden hast. Er soll gerade dazu dienen, die Details im Speicher zu halten, auf die zuletzt zugegriffen wurde. Wenn nun diese Liste der Objektreferenzen die einzige Referenz auf das Objekt hält, und es deswegen nicht aufgeräumt wird, macht die Liste doch genau das, wofür sie gedacht ist. Oder habe ich das komplett missverstanden?

@MiK: Du darfst auch gerne alle getter- und setter-Methoden wieder ausbauen. Der direkte zugriff auf die Felder ist sicher schneller.

Ich bin kein großer Freund von großen Umbauaktionen aus rein philosophischen Gründen. Und deswegen werde ich es auch nicht zurück umbauen. Generell ist mein Ansatz, dass ich nur Getter/Setter benutze, wenn es für diese Member einen konkreten Grund dafür gibt. Aber ich habe auch nichts dagegen, wenn es jemand anders macht.

 

[Engywuck]

Oder habe ich das komplett missverstanden?

Ja. Ich habe allerdings auch keine Lust, es nochmal zu erklären.

 

[pfeffer]

nein, MiK hat es richtig verstanden, jedenfalls war das der Sinn, warum ich es damals gebaut habe.

Getter und Setter sehe ich genauso wie MiK. Also: Getter und Setter nur dann, wenn dabei irgendein weiteres Objekt weiter benachrichtigt werden muss, oder Berechnungen durchgeführt werden müssen, oder andere Daten (mit-) aktualisiert werden müssen.
Eine generelle Umstellung auf Getter und Setter halte ich für unnötiges Aufblasen des Codes und unnötige Verlangsamung.
Aber wenn es jemand bei neuem Code immer macht, von mir aus. Bestehenden Code unnützerweise auf Getter-Setter umstellen, finde ich doof.

Ansonsten: Bitte nimm es nicht persönlich, ich freue mich, dass Du den Cachewolf vorrang bringst.

Gruß,
Pfeffer.

EDIT: Ich bin schon für Umbau aus "rein philosophischen" Gründen, wenn die Struktur vermurkst ist, wie z.B. bei der MovingMap.java. Eine gute logische Struktur ist schon wichtig für die weitere Entwicklung. Ebenso solcher Quatsch, Zahlen als Strings zu speichern oder so ein Murks, ist schon eine Grund. Kurz vor einem Release sollte man sowas natürlich nicht machen. --> ist im Moment also möglich.

EDIT2: Auch die Umstellung auf CacheHolder und CacheHolderDetails von Dir, war wichtig. Und dabei sind die Getter und Setter ja auch essentiell.

 

[Engywuck]

nein, MiK hat es richtig verstanden, jedenfalls war das der Sinn, warum ich es damals gebaut habe.

Damals, ja.

 

[MiK]

Und warum soll dieser Sinn jetzt nicht mehr gegeben sein?

 

[Engywuck]

Dann lies noch mal den Anfang dieses Threads.

 

[Engywuck]

Nachtrag:
So langsam gehen mir hier echt die Haare hoch. Der Code hat (bis auf das Problemchen mit dem OC-Download) hervorragend funktioniert. Dann kommt jemand und ändert die Keys einer kleinen Hilfsliste von String auf Objekt. Ok, das kann man wieder geradeziehen und an der richtigen Stelle korrigieren.
Aber das ist ja nicht gewollt. Stattdessen kommt noch jemand anders, der nach eigenen Aussagen weder den einen noch den anderen Code kennt, aber will auf Basis dieses fundierten Eindrittelwissens beurteilen, warum der Code, der bisher erfolgreich seine Arbeit tut, so nicht funktionieren kann.

Ich hab echt keinen Bock mehr, mich hier ständig für funktionierenden Code rechtfertigen zu müssen. Wenn ihr alles besser könnt, könnt ihr es gefälligst auch selber machen. Ich werd mich um die Dinge kümmern, die für mich persönlich wichtig sind, für alles andere haben wir ja unsere Spezialisten.

Viel Spaß.

 

[Engywuck]

Und ja: diese Routine wird beim OC-Download-Import sehr oft gebraucht. Bei jedem Wegpunkt, bei jeder Cachebeschreibung, bei jeden Bild und vor allem bei jedem Log.

Was Du hier schreibst, ist hanebüchener Unsinn. Aber vermutlich wäre es zuviel verlangt, Dein Eclipse mal zu fragen, an welcher Stelle das Objekt cachesWithLoadedDetails überhaupt verwendet wird, und sich den Kontext mal kurz anzugucken.

sorry, aber Objektorientierung lebt von Objektreferenzen.

Die Referenzen sind ja auch vorhanden. Aber an der Stelle, an der sie hingehören.

 

[pfeffer]

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?

Bei mir steht in diesem Bereich:

		if (name.equals("desc")){ // </desc>
			if (holder.is_HTML())	holder.getFreshDetails().LongDescription +=SafeXML.cleanback(strData);
			else holder.getFreshDetails().LongDescription +=strData;
			return;
		}

Meintest Du diese Stelle, oder hat sich das inzwischen verschoben?
Es ist bei Opencaching so, dass es zu einem Cache mehrere Beschreibungen geben kann - nämlich in unterschiedlichen Sprachen. Deswegen wird in den Zeilen 594-603 je nach dem, ob die Beschreibung bereits einmal upgedated wurde, die Beschreibung ersetzt oder durch eine neue Sprache ergänzt. Das ist so nicht ganz sauber, weil Cachewolf die Sprach-Namen einfach als Überschrift in die Beschreibung einfügt und die Beschreibung sich nicht für jede Sprache separat speichert.
Ich weiß leider nicht, ob opencaching wenn die Beschreibung 2mal geändert wurde, beide Änbderungen bei der Abfrage liefert. In diesem Fall könnte es dazu kommen, dass die 1. Änderung und die 2. Änderung aneinander gehängt werden. Ich konnte das bisher nicht ausprobieren, weil ich das von keinem Opencaching-Cache weiß.
Hättest Du ein Beispiel dafür?

Besten Gruß,
Pfeffer.

 

[Engywuck]

Ich habe auch nur eine Datei manuell geändert und dann im CW aktualisiert.

 

[pfeffer]

Das heißt, Du hast kein falsches Verhalten festgestellt für den Fall, dass man nicht manuell in den Daten herumfummelt? ää - also positiv formuliert: kein Fehler gefunden, nur beim Debuggen unerwartetes Verhalten, das ich jetzt aber erwartbar gemacht habe?

Gruß,
Pfeffer.

 

[Engywuck]

Ich wollte den Fall simulieren, dass die Cachebeschreibung vom Owner geändert wurde. Da ich keinen Cache zur Verfügung habe, den ich zu Testzwecken ändern konnte, habe ich einfach den Inhalt der XML-Datei geändert und dann so getan, als sei das der alte Stand, den ich nun mit der neuen Beschreibung online aktualisieren will. Oder kann man das bei OC nicht so machen ?

 

[pfeffer]

ich habe einen Cache bei Opencaching ( http://www.opencaching.de/viewcache.php?cacheid=115464 ), Habe den mal testweise geändert und konnte keine Probleme feststellen.

Gruß,
Pfeffer.

 

[Engywuck]

Sieht das anders aus, wenn Du die Dateil manuell bearbeitest und dann aktualisierst?

Gruß,
E.