You are viewing a single comment's thread from:
RE: Steem Data Services (SDS) / Update Notice / Version 0.1.7b
Cool! Danke für deine Arbeit! 👍
New API Module
post_tags_api
Die API ist schon sehr interessant. Das erspart mir das Durchlaufen von Posts. Bin gespannt, welche Methoden du da noch einbaust. TagsByCommunity und TagsByAuthor wären sehr nützlich für eine Community- und Autorenseite.
I worked really hard on this one to get the database size as small as possible.
Würde mich schon interessieren, wie du das gemacht hast. Könnte aber auch verstehen, wenn du hier nicht alle deine Algorithmen offenbaren möchtest.
Bedeutet das, dass du für jede API eine eigene Datenbank führst, die mit jedem Block aktualisiert wird?
Da sich die Version noch in der Testphase befindet und ich aufgrund eines festgestellten Bugs heute sowieso einen kompletten 're-parse' starten muss, bevor sie in Produktion gehen kann, werde ich bei der Gelegenheit die
post_tags_apinoch etwas erweitern. Mehr Details dazu demnächst ;)Ja, der Parser durchläuft die Blöcke und ruft entsprechende Events in den über die Config aktivierten Modulen auf (soweit das jeweile Modul nicht bereits bei einer höheren Blocknummer ist). Die Module können natürlich auch untereinander verknüpft werden, um Daten anderer APIs direkt abrufen zu können.
Jedes Parser-Modul verwendet normalerweise mindestens eine eigene Datenbank, die aber auch untereinander verknüpft (attached) werden können. Über die Config kann man auch festlegen, dass eine Datenbank für mehrere oder sogar alle Module verwendet werden soll, aber das würde ich aus Performance- und Wartungs-Gründen nicht empfehlen.
Es lassen sich auch Daten aus anderen Modulen direkt in SQL-Abfragen joinen, daher hat es deutlich mehr Vorteile die Datenbanken zu trennen und so unfragmentiert wie möglich zu speichern.
Die Aufteilung bringt zudem auch hinsichtlich der Verminderung der Redundanz sowie der im Notfall erforderlichen Wiederherstellung Vorteile. Allerdings wirst du dir dazu im Vorfeld wohl sehr viele Gedanken über die Art und Weise der Aufteilung und anschließender Verknüpfung (durch die SQL-Abfragen) gemacht haben. Dabei den Überblick zu behalten, ist nicht ohne.
Für den privaten Bereich habe ich ein paar mehr oder weniger komplexe Datenbanken erstellt und mit entsprechenden Abfragen und Codezeilen versehen. Insofern habe ich ungefähr eine Vorstellung davon, welchen Aufwand du mit der effizienten Speicherung der Daten der gesamten Blockchain hattest/hast.
Bin gespannt. :-)
Heute hatte ich noch einen neuen Gedanken. Oftmals interessiert mich, bei welchen Posts neue Kommentare eingestellt wurden und würde danach gern sortieren, damit man auch neue Kommentare in älteren Posts nicht übersieht. Für jeden einzelnen Post bekäme man das mit den Replies auch raus. Allerdings ist dies für eine Post-Liste (z. B. aus der
feeds_api) nicht ganz so "unaufwendig", da man erst zu jedem Post in der Liste die Replies abrufen müsste.Wäre es anhand der Daten in deinen Datenbanken (unkompliziert) machbar, in der Response (z.B. nach
feeds_api.getCommunityPostsByCreated) auch den Timestamp des letzten Kommentars zurückzugeben?Mir gefällt deine Idee und ich denke, dass ich ein Feld
last_replyin allen Feed-Listen für Root-Posts problemlos zurückgeben könnte. Wahrscheinlich wird das aber erstmal nur für neue Kommentare (Erstellungszeitpunkt) funktionieren, da ich sonst einen weiteren Index für das Feldupdated(das den Zeitpunkt der letzten Änderung enthält) brauchen würde.Ich schau mal, was ich da machen kann.
Das wäre doch sehr gut. Ich denke, es wäre nicht weiter tragisch, wenn es zunächst nur die neuen Kommentare funktioniert. Das wird sich dann ja nach und nach ändern.
Wenn du es eingebaut hast, wäre eine Info gut, damit ich weiß, wie das feld
last_replyzurückgegeben wird, wenn es keine (oder keine neuen) Kommentare gibt.