da muss ich wohl etwas weiter ausholen...

2011-01-07T21:58:22 bianca

2011-01-07T21:32:11 pq

und wie löse ich dann das problem mit gelesenen threads? speicherung pro artikel statt timestamp pro thread?

Wie ist denn derzeit die Logik aufgebaut, nach der ungelesene Beiträge beim Anklicken eines Threads aufgeklappt sind und der Rest zugeklappt ist?
Könnte man an der Stelle nicht anknüpfen und die zugeklappt-Eigenschaft ersetzen durch garkeinen Text und das zugehörige Plus-Icon anders verlinken zu einem JS, dass bei Klick den Text nachlädt und per .innerHTML dort einfügt?

selbstverständlich. über die technischen details brauchen wir uns da nicht unterhalten.

ich sagte aber doch dazu ein paar dinge. diese lösung skaliert nicht. schau dir den kephra-thread an und stell dir vor, der wär ein baum.
wenn du hunderte beiträge hast, dann wird es trotzdem zu viel für eine seite. deshalb muss irgendwann eine lösung her, auch einem baum auf mehrere seiten aufzuteilen. die frage ist nur wie. es geht auch um die performance im background. gäste rufen ja solche langen threads auch auf. das kostet dann auch traffic und cpu. d.h. es muss da auf jeden fall was gemacht werden, und ich mag daher nicht zuerst den aufwand mit dem nachladen machen, wenn es nur teilweise etwas bringt und man das problem durch eine andere lösung auch in den griff kriegen würde.

Quote

2011-01-07T21:32:11 pq

zu welcher seite geht man, wenn ein thread jetzt mehrere seiten hat und auf mindestens zwei dieser sich ein ungelesener artikel befindet?

Welche Seitenaufteilung meinst Du?

na wie ich schon sagte, man muss einen baum ggfs. auch in mehrere seiten aufteilen können. der thread, den du als beispiel gegeben hast, ist dafür das beste beispiel, denn er ist nicht geeignet für viele teilbäume, der ist eher lang als tief verschachtelt.
das skaliert so nicht.

Quote

2011-01-07T21:32:11 pq

ausserdem muss ich bei allen lösungen beachten, ob man das sinnvoll cachen kann, das ist ja auch eine der stärken des forums.

Wenn ich caching lese denke ich immer an Ladezeit kontra Aktualität. Übersehe ich etwas? Worum genau geht es beim caching eines Forum?

ich weiss nicht, ob ich hier in länge und breite nochmal den caching-mechanismus von battie ausführen soll. gegenfrage: wie stellst du dir das forum vor? glaubst du z.b., dass jeder beitrag bei jedem aufruf neu gerendert wird? in einem beitrag gibt es z.b. verweise wie [thread://123]. daraus wird dynamisch der titel geholt und angezeigt. das kostet zeit.

bei der anzeige eines threads hole ich mir alles in die richtige struktur in form von objekten und speichere das in einem cache (filecache oder memcached z.b.). bei erneutem aufruf wird die struktur nur herausgeholt, ggfs. kleine änderungen gemacht, die userabhängig sind (z.b. gelesen? ja/nein) und das ganze ans template geschickt. so spar ich mir das erneute aufbauen der struktur aus der flachen datenbank und das rendern von bbcode.
der thread wird nur wenige minuten gecacht, aber das ist ausreichend, da der regelfall ist, dass nur wenige aktuelle threads gerade beliebt sind, und bei denen lohnt dann das caching.

bei einer wichtigen änderung lösche ich den cache dieses threads explizit.

nach demselben verfahren cache ich die beiträge der letzten 24h, die liste der gerade aktiven user usw. usf.

Quote

2011-01-07T21:32:11 pq

um eine gelesen-markierung für jeden einzelnen artikel komme ich wohl nicht drumherum, das kann für mehrere sachen nützlich sein. dann müsste ich aber den kompromiss machen und regelmässig alte markierungen löschen, da das sonst grosse datenmengen wären.

Bin mir nicht sicher. Wenn man pro Thread und User einen Timestamp des letzten Besuchs speichert kann man daraus doch ableiten, welche Beitrag neuer und daher ungelesen sind. Oder sehe ich das falsch?

sicher. das war ja auch so in der allerersten implementierung.
dieser code (und die datenbankstruktur) hat eine kleine änderung erfahren, als ich die teilbäume implementiert habe. seitdem speichere ich pro teilbaum einen timestamp. du siehst, dein vorschlag ist leider schon zu simpel für die teilbäume gedacht.

hat man jetzt noch die möglichkeit, den baum in seiten aufzuteilen, reicht auch das nicht mehr, da ein user einen teil zuerst aufrufen kann, der neuer ist. dadurch würde aber dann der ältere teil auch als gelesen markiert sein und man überliest ihn beim nächsten aufruf.
es bleibt wirklich nur die speicherung eines timestamps pro user und beitrag statt pro thread. und, ich wiederhole mich, das könnten dann einige datenmengen werden, so dass ich mir überlegen muss, nach welchen kriterien ich solche datensätze nach einiger zeit lösche.
für dieses forum wäre sicher alles von der menge her handhabbar, aber ich wills dann auch richtig machen, wenn ich es mache.