Verweilzeit der Beiträge in der Hauptdatei
Stefan Einspender
- zu diesem forum
Hallo ForumsleserInnen,
meiner Meinung nach ist die Dauer, die die Postings derzeit in der
Hauptdatei haben, zu kurz eingestellt.
Bsp:
Am Dienstag kam ein Thread zustande, wo es u.a. um den Userstring
von AOL-Browsern ging. Das letzte Posting erfolgte imho am Mittwoch,
am Donnerstag früh erhielt ich eine e-Mail, dass noch jemand seinen
Beitrag posten will, sobald er wieder Zugriff auf sein AOL hat.
Wahrscheinlich hat er es gestern dann nicht mehr geschafft, eben
schaue ich und der Thread ist bereits weg :(
Damit ist es nicht mehr möglich, nach nur zwei Tagen da noch etwas
hinzuzufügen, imho ist diese Zeitspanne deutlich zu kurz. Wenn sich
jemand z.Bsp. nur auf Arbeit hier beteiligt und Freitags eine An-
frage hat, dann ist am Montag u.U. schon der ganze Thread weg.
Noch dazu kommt momentan die Situation, dass diese Beiträge im
Nirvana verschwinden :(
Ist es möglich, die Parameter etwas zu verändern oder zumindest die
Sache so einzustellen, dass ein Thread nach dem Herausfallen weiter-
hin ca. 1 Woche am alten Platz erreichbar ist, allerdings ohne Ant-
wortmöglichkeit?
Damit würde auch verhindert, dass es tote Links gibt, wenn ich hier
in meinem Posting auf einen Thread weiter unten verweise.
Viele Grüße aus Dresden,
Stefan Einspender
PS:Bitte kein Verweis auf sf.net, es handelt sich bei meinem Problem
weniger um eine technische Angelegenheit als vielmehr ein Problem
eben "Zu _diesem_ Forum", danke.
hi!
meiner Meinung nach ist die Dauer, die die Postings derzeit in der
Hauptdatei haben, zu kurz eingestellt.
Das Problem ist, dass dann die Hauptdatei sehr groß werden würde.
Und die muss ja nicht nur zum Anwender übertragen, sondern nebenbei
auch noch auf dem Server geparst und ausgewertet werden.
Dem ersten Problem könnte man später evtl. damit begegnen, dass die
Userkomponente es erlaubt, die Maximalanzahl der Postings etc., die
angezeigt werden sollen, anzugeben. Dazu könnte man auch vermutlich
die Menge der gespeicherten Threads anders einstellen als die Menge
der standardmäßig angezeigten Threads.
Das zweite Problem ist aber wohl nicht so einfach zu umgehen. Da
müssen wir uns mal unterhalten, was denn maximal in der Forums-XML
speicherbar ist, bevor wir Performance-Probleme kriegen. Denn davon
dürfte die Lösung wohl hauptsächlich abhängen.
bye, Frank!
Hallo Stefan,
Ist es möglich, die Parameter etwas zu verändern oder zumindest die
Sache so einzustellen, dass ein Thread nach dem Herausfallen weiter-
hin ca. 1 Woche am alten Platz erreichbar ist, allerdings ohne Ant-
wortmöglichkeit?
Damit würde auch verhindert, dass es tote Links gibt, wenn ich hier
in meinem Posting auf einen Thread weiter unten verweise.
das läßt sich allein durch Änderung der Parameter nicht verhindern.
Das dynamische Archivierungsverfahren bewirkt, daß Du vorher keine
Information darüber bekommen kannst, welches Postings vor oder nach
welchem anderen aus dem Forum-Cache entfernt wird. 'oben' und 'unten'
sind also irrelevant.
Zwei Fälle fallen mir spontan ein:
a) Posting X linkt auf Y, Y wird zuerst archiviert.
Dann kann der Archivierer im Mmoment dieser Archivierung den Verweis
innerhalb von X auf den URL des Threads im Archiv anpassen - denn er
weiß, daß Y nach Y' archiviert und nicht etwa gelöscht wurde.
(Würde Y nicht archiviert, sondern gelöscht, dann könnte der Verweis
auf 'inaktiv' mit einem entsprechenden Vermerkt gesetzt werden.)
Aber wer sagt dem Archivierer, daß X einen Verweis auf Y enthält?
Dazu sollten schon beim Entstehen von X (also beim Posten!) alle
Verweise zwischen Postings zusätzlich separat gespeichert werden
(also eine Relation mit dem Eintrag (Y, X) mit der Bedeutung: "Wenn
Y vom Archivierer bearbeitet wird, dann passe den Inhalt von X an").
Der Archivierer tut dann genau dies - und löscht den Eintrag aus
dieser Tabelle wieder.
b) Posting X linkt auf Y, X wird zuerst archiviert.
Egal, ob Y später gelöscht oder archiviert wird, zum Zeitpunkt der
Archivierung von X nach X' steht das noch nicht fest.
Der URL von Y ändert sich aber durch seine spätere Archivierung;
die nun anzupassende Stelle befindet sich jedoch bereits im Archiv!
Die in a) beschriebene Relation könnte der Archivierer dafür nutzen
und im Moment der Archivierung von X den Wert (Y, X) auf (Y, X')
umschreiben.
Während der Archivierung von Y ist dann feststellbar, daß in X' ein
anzupassender Link existiert; wird schließlich Y archiviert (oder ge-
löscht - das ist egal), dann wird X' im Archiv nachträglich geändert.
Es gäbe also drei Zugriffe auf diese Tabelle:
Da Links zwischen Postings ein seltener Fall sind, dürfte ein "full table
scan" auf diese Relation (mit wenigen Einträgen) performancemäßig völlig
ausreichen.
Viele Grüße
Michael
P.S.: Was habe ich noch alles übersehen?
(dieser Beitrag wurde nach SourceForge übernommen)
Hallo Michael,
[...]
stimmt, habe ich soweit verstanden und ist wohl auch durchaus so um-
setzbar.
Alternative:
Beim Abschicken eines Postings mit einem Link auf ein anderes Posting
erhält dieser Link eine automatisch generierte, fortlaufende ID, aus
link?m=125931&t=24165 wird automatisch link?ID=34223
In einer Tabelle stehen die Zuordnungen zwischen den ID´s und dem
Ort des dazugehörigen Postings.
Wenn ein Posting aus der Forumshauptdatei verschwindet, bleibt es
noch mind. 24h unter der alten URL erreichbar (ID stimmt also noch).
Jedes dieser Postings besitzt keine Antwortmöglichkeit mehr und ent-
hält einen Hinweis, wohin es archiviert wurde oder ob es gelöscht
wird.
Einmal täglich (nachts) wird die Tabelle mit den ID´s nach Einträgen
durchsucht, die auf aktuelle Postings verweisen und es wird geprüft,
ob darunter auch aus der Hauptdatei entfernte Postings sind. Wenn ja,
dann wird in der ID-Tabelle automatisch der Eintrag geändert, ent-
weder auf den Archiv-URL oder auf einen Standardseite "Dieses Posting
wurde nicht archiviert und ist nicht mehr verfügbar"
Auf diesem Weg vermeidet man, irgendetwas in den Postings ändern zu
müssen, lediglich die ID-Tabelle muß einmal täglich überprüft und
gegebenenfalls geändert werden (nur Einträge, die auf aktuelle
Postings verweisen). Natürlich wird diese Tabelle nach und nach
immer größer, aber aufgrund der recht niedrigen Anzahl von internen
Links dürfte dieses Vorgehen vertretbar sein.
Das Script, welches beim Absenden eines Postings die ID erzeugt, muß
darauf optimiert werden, die vielfältigen Möglichkeiten solcher
Links zu erkennen, aber das ist ja bei Deinem Vorschlag ebenfalls
notwendig.
Viele Grüße aus Dresden,
Stefan Einspender
Hallo Stefan,
Beim Abschicken eines Postings mit einem Link auf ein anderes Posting
erhält dieser Link eine automatisch generierte, fortlaufende ID, aus
link?m=125931&t=24165 wird automatisch link?ID=34223
In einer Tabelle stehen die Zuordnungen zwischen den ID´s und dem
Ort des dazugehörigen Postings.
Du erfindest also eine zusätzliche alternative Bedeutung eines Links?
Das möchte ich vermeiden. Und Deine zu pflegende Tabelle bedeutet
denselben Aufwand wie bei meinem Vorschlag.
Jedes dieser Postings besitzt keine Antwortmöglichkeit mehr und ent-
hält einen Hinweis, wohin es archiviert wurde oder ob es gelöscht
wird.
Und in Abhängigkeit von welchen Ereignissen wird dieser Hinweis von wem
erkannt?
Einmal täglich (nachts) wird die Tabelle mit den ID´s nach Einträgen
durchsucht, die auf aktuelle Postings verweisen und es wird geprüft,
ob darunter auch aus der Hauptdatei entfernte Postings sind.
Also eine zusätzliche Housekeeping-Funktion. Wer aktiviert diese?
(Bisher wird nur CGI benötigt, kein cron etc.)
weder auf den Archiv-URL oder auf einen Standardseite "Dieses Posting
wurde nicht archiviert und ist nicht mehr verfügbar".
Genau das möchte ich auch - aber schon in dem Moment, wo diese Informa-
tion verfügbar ist.
Das paßt m. E. harmonischer in das bisherige Konzept des Forums, wo ja
auch die Archivierung implizit vom Posting-Vorhang ausgelöst werden kann.
Das Forum verhält sich wie eine relationale Datenbank, mit Transaktions-
prinzip. Das möchte ich nicht unterlaufen.
Auf diesem Weg vermeidet man, irgendetwas in den Postings ändern zu
müssen, lediglich die ID-Tabelle muß einmal täglich überprüft und
gegebenenfalls geändert werden (nur Einträge, die auf aktuelle
Postings verweisen).
Mir gefallen ausschließlich konsistente Zustände der XML-Strukturen besser.
Natürlich wird diese Tabelle nach und nach
immer größer, aber aufgrund der recht niedrigen Anzahl von internen
Links dürfte dieses Vorgehen vertretbar sein.
Weia - wo ist die Cleanup-Funktion dafür? Unlimitiertes Wachstum einer
Tabelle (selbst einer kleinen) ist sicherlich nicht ästhetisch.
Viele Grüße
Michael
Hallo nochmal,
Und in Abhängigkeit von welchen Ereignissen wird dieser Hinweis von wem
erkannt?
Der Hinweis wird erkannt, wenn einmal täglich die ID-Tabelle durch-
geschaut wird und die aktuellen Posting überprüft werden. Dann ist
dieser Hinweis wichtig, um eine Änderung dieses Eintrages in der
ID-Tabelle zu veranlassen.
Also eine zusätzliche Housekeeping-Funktion. Wer aktiviert diese?
(Bisher wird nur CGI benötigt, kein cron etc.)
Stimmt natürlich schon, die Aktion (und auch das Löschen der alten
Postings) muß irgendwo automatisch oder manuell gestartet werden.
Weia - wo ist die Cleanup-Funktion dafür? Unlimitiertes Wachstum einer
Tabelle (selbst einer kleinen) ist sicherlich nicht ästhetisch.
Ja, darin sehe ich auch den größten Schwachpunkt meines Vorschlages.
Diese Situation entsteht bei Deiner Variante nicht, weshalb sie wohl
zu bevorzugen wäre ;)
Danke für die Hinweise.
Viele Grüße aus Dresden,
Stefan Einspender