Zum Inhalt springen

Cachepflege in GSAK via API


TommiB

Empfohlene Beiträge

Aufgrund meiner erstellten Doku wurde ich um Folgendes angefragt:

 

Wie du habe ich für das Importieren der ganzen Schweiz PQ's analog deinem Vorschlag erstellt. Danach habe ich jedoch diese deaktiviert und führe nun täglich ein PQ aus, dass nur noch die ‘Neuen‘ und ‘Updated in the last 7 days‘ Caches ausweist. Dieses PQ importiere ich täglich in meine Datenbank.

 

Danach führe ich über das Geocaching.com api folgende Funktionen über die komplette Datenbank aus:

- ‘Download logs…‘ bzw. ‘Get recent logs…‘

- ‘Status check…‘¨

Beide Funktionen haben keine Limits auf Anzahl Caches ;-)

 

Nun weise ich über Filters alle die ‘Archived and Not Found‘ und die ‘Temporarily and Not Found‘ Caches aus und lösche die aus der Datenbank.

 

Bist Du der Meinung mir entsteht dadurch einen Nachteil? Oder habe ich etwas in meinen Überlegungen vergessen?

 

 

Meine erste Antwort war dann:

 

So auf die Schnelle kommen mir dazu folgende Gedanken:

  • Die Funktionen über die API dauern wohl länger als das runterladen der PQs (wie lange dauert das bei Dir?)
  • Mit den PQs könnte man bei Bedarf auch mal ein GPS direkt füttern (gut, kann man auch mit einem Export aus GSAK)
  • Was ich nicht machen würde, ist das Löschen der temp. unavailable und der nicht gefundenen. Sonst kommen die ja nicht mehr in die DB zurück, wenn sie dass wieder aktiv sind. Ich würde sie nur mit einem Filter vom Export auf das GPS ausgrenzen

 

Die Rückantwort:

 

Zu deinen Anmerkungen:

  • Ja, die Funktionen über das API dauert länger als das Importieren der PQ's (Mache ich über die Nacht und dauert zur Zeit ca. 7h )
  • Das Löschen sehe ich nicht so problematisch, da ich ja in meinen PQ für die neuen Caches das Flag 'Updated in the last 7 days‘ gesetzt habe und ich dadurch die reaktivierten Caches wieder bekomme.
  • Aber dein Ansatz, für das Exportieren aufs GPS einen Filter zu schreiben ist natürlich auch toll :thumbup:

 

Worauf ich dann bezüglich Löschen antwortete:

 

Das gilt aber ja nur für Caches, welche eben in den letzten Wochen PUBLIZIERT worden sind. Wird ein ALTER Cache temp. disabled und danach wieder aktiviert, verlierst Du ihn so. Oder?

 

Nun nimmt es mich natürlich brennend Wunder, was die GSAK-Experten dazu meinen... Wär das ne Alternative? Irgendwelche Anmerkungen, Einwände, ist was vergessen gegangen?

 

En Gruess, tommiB

Link zu diesem Kommentar
Auf anderen Seiten teilen

Selten kommt es vor, dass wir einen archivierten Cache wieder auferleben lassen. Wird der archvierte Cache nun in der DB definitiv gelöscht, dann kommt der über api (get Logs, Status update )nicht wieder, da er ja nicht in der DB drin ist. Und neu publiziert ist er ja auch nicht.

Darum finde ich das von tommib vorgechlagene Vorgehen besser, diese in der DB zu behalten und beim Überspielen auszugrenzen

Bearbeitet von Antefix
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich sehe das gleich wie tommib und Antefix. Ich lösche archivierte Caches auch nicht, sondern verschiebe diese in eine separate DB, temp. disabled bleiben in der Haupt-DB.

 

Für den seltenen Fall, dass ein archivierter Cache wieder aktiviert wird, ist der dann halt sowohl in der "Archived" DB wie auch in der Haupt-DB drin, damit kann ich aber gut leben.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo TommiB

 

Betreffend dem 'wiederbeleben' von 'Temporarily and Not Found' und 'Archived and Not Found' hast du natürlich recht...

 

Bei einer schnell Überprüfung bin ich auf das gleiche Ergebnis gekommen ;). Habe gedanklich eine und/oder Verknüpfung gemacht, was natürlich nicht der Fall ist.

 

Das heisst meine Variante, betreffend dem 'wiederbeleben' von 'Temporarily and Not Found' und 'Archived and Not Found' funktioniert nicht :wacko:.

 

Um dies zu Umgehen, scheint mir dein Vorschlag, die 'Temporarily and Not Found' und 'Archived and Not Found' oder eben auch nur die 'Temporarily and Not Found' in der Datenbank zu lassen und ein Filter für das Übetragen auf GPS zu schreiben, eine ganz gute Lösung.

 

Betreffend dem aktualisieren der Cachedaten, tendiere ich auch immer mehr zur Lösung, wie du sie in deinem Dokument 'GSAK und Pocket Queries, Filter, GPS-Download' beschrieben hast und ich es ursprünglich ja auch gemacht habe, da die Updatezeiten über das API wirklich sehr lange sind :angry:.

 

Ok, ich gebe zu, ich habe mich mit meiner Frage etwas blamiert bzw. wirklich nicht alles berüchsichtig :D. Trotzdem noch eine weitere Frage an die GSAK-Experten. Macht es nach eurer Meinung Sinn, jeden Tag einen Statuscheck über das APIzu machen? Dadurch werden die Stati in der DB doch wenigstens tagesaktuell... Diese Funktion dauert über die ganze Datenbank 'nur' ca. 20 Minuten.

 

Vielen Dank für die hilfreichen Tipps

die3besten

Link zu diesem Kommentar
Auf anderen Seiten teilen

...Ok, ich gebe zu, ich habe mich mit meiner Frage etwas blamiert bzw. wirklich nicht alles berüchsichtig...

 

Erstens gibts nichts zuzugeben und zweitens kann man sich mit so einer Frage nicht blamieren :P Fragen sind da um gestellt zu werden...

Den Hinweis mit dem Statuscheck finde ich gut. Ich würde das vermutlich machen, wenn ich an einen Ort auf Tour gehe und mir die entsprechenden Caches filtere.

 

En Gruess, tommiB

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo zusammen

 

Ich aktualisiere meine Caches via 1000er PQ's. Die Archiverten bleiben als solche markiert in der DB und werden bei den verschiedenen Exporten rausgefiltert...

 

Manchmal vor einer Tour aktualisiere ich einige hundert Caches mit "Refresh Cache Data" um die letzten Änderungen zu erhalten.

 

Das man die ganze DB jeden Tag via API neu halten will, hängt dann wohl vom User ab.

 

Gruess Salbedo

Link zu diesem Kommentar
Auf anderen Seiten teilen

Warum die grosse Mühe? Natürlich kann man täglich den Status aktualisieren aber wozu? Ist es wichtig, ob der Cache im GSAK aktiv oder disabelt ist, wenn ich ihn nicht aufs Gerät lade?

 

Ich aktualisiere erst, wenn ich den Filter gesetzt habe bevor ich es aufs GPS lade. Dann sind es auch wenige Caches und die Aktualisierung geht schnell.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das PlacedPQ.gsk macro hilft einem dabei, die optimalen Datumsbereiche für seine PQs zu definieren. Damit es funktioniert, brauchst Du schon mal alle Caches einer Region in der DB, aber anhand des Macros kannst Du die Anzahl benötigter PQs minimieren, die Du erstellen musst. Sind diese einmal erstellt, kostet die Lösung über PQs eigentlich kaum mehr Aufwand (1x täglich "Download PQ" wählen) und Du hast garantiert immer eine DB, deren älteste Information maximal eine Woche alt ist.

 

Benötigst Du für ein Subset daraus tagesaktuelle Informationen (z.B. Logs oder Status) kannst Du mit einem Filter einen Refresh machen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...