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:

• beim Posten von X      (INSERT "Y,X"),
• beim Archivieren von X (UPDATE "Y,X" -> "Y,X'"),
• beim Archivieren von Y (DELETE "*,Y").
  Plus die entsprechenden Änderungen in X bzw. X'.

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)