1000 berichten-grens

[Jk_W]

Het is al sinds GoT-heugenis een traditie om een topic te sluiten bij 1000 berichten en een volgend deel te creeeren. Dit gebeurde vroeger om lay-out redenen. Tegenwoordig is deze reden echter achterhaald en kan een topic veel groter worden. (Zie bijvoorbeeld het Koninginsplein-webcam topic).

Bij veel topics is het handig om een nieuw deel te openen, zodat de topicstart geupdate kan worden, maar bij veel topics is het echter totaal nutteloos geworden. Een voorbeeld is bijvoorbeeld het "heb je iets nieuws en je moet het gewoon showen" topic. Ik zie hierbij geen reden om een nieuw topic te openen om de 1000 posts. Deze grens kan veel hoger of zelfs helemaal verdwijnen. Wat is de reden dat dit nog niet is gebeurd? Is het puur nostalgie of zit er meer achter?

Ik ben benieuwd hoe de users en de modjes hierover denken.

[silverstorm]

1) mensen die oude lay-outs gebruiken
2) het is nogal vervelend om een topic te zien waarin je 2 jaar geleden hebt gereageerd en deze steeds in je posthistory naar boven geschopt te zien.
3) hoe bepaal je wanneer je wel een nieuw topic mag openen. Nu is er een regel die zegt dat het bij 1000 posts is. Ander wil $user1 bij 1000 een nieuwe post maken en $user2 vind dat het zo door kan, en dan kan je 2 topics door elkaar krijgen.

[ Voor 39% gewijzigd door silverstorm op 06-05-2007 20:08 ]

[Harm]

4) In ieder geval vroeger was het zo dat React traag werd bij het openen van een topic met veel reply's

[Apen-nootjes]

Harm schreef op zondag 06 mei 2007 @ 20:22:
4) In ieder geval vroeger was het zo dat React traag werd bij het openen van een topic met veel reply's

Bij veel, heel veel replies is dat nog steeds zo

[TERW_DAN]

De reden is puur overzichtelijkheid. Een grens is er niet echt fysiek (in het crewtopic loopt een topic dat nu al iets van 50.000 posts lang is ofzo, althans, ze zijn er bezig een zo lang mogelijk topic te maken ).
Persoonlijk vind ik het wel makkelijk. Nu is een topic gewoon 1 pagina lang, dan gaat het op slot

[fsfikke]

Ookal zijn het meestal de externe avatars en andere content es die het zaakje vertragen (ookal is dit natuurlijk wel uit te schakelen)
Maar opent een topic met 1000 replys trager dan een topic met 100? Hij laat toch alleen maar bijvoorbeeld 50 posts zien?

[Boudewijn]

silverstorm schreef op zondag 06 mei 2007 @ 20:06:
1) mensen die oude lay-outs gebruiken

ik merk er niets van met de paarse layout hoor.

echter bij DMs wel (ik heb een draad met momenteel 2932 posts) en dat ziet er niet meer uit in mijn overzicht.

[Dancing_Animal]

Van mij mag de grens eigenlijk ook wel omhoog. Als ik kijk naar de topics over bijvoorbeeld monitoren zitten die best wel snel vol. In een volgend topic krijg je dan weer dezelfde vragen die al beantwoord zijn in 1 of meer van de vorige delen. Dan kan het makkelijker zijn om in minder topics terug te hoeven graven. Ik vraag me trouwens ook af of de breedte van de topics niet groter kan. Kun je ook veel overzichtelijkere tabellen maken. Ik denk niet dat er veel mensen zijn die nog op 800x600 draaien.

[krvabo]

fsfikke schreef op zondag 06 mei 2007 @ 20:31:
Ookal zijn het meestal de externe avatars en andere content es die het zaakje vertragen (ookal is dit natuurlijk wel uit te schakelen)
Maar opent een topic met 1000 replys trager dan een topic met 100? Hij laat toch alleen maar bijvoorbeeld 50 posts zien?

De query moet wel alle records doorlopen, en daarna de eerste 50 pakken
Dus ja, het is trager.. al is het verschil tussen het weergeven van:
= de eerste 50 posts uit een topic met 100 posts
= de eerste 50 posts uit een topic met 500 posts
Niet extreem veel langzamer, of zelfs nauwelijks.

[ Voor 38% gewijzigd door krvabo op 06-05-2007 20:35 ]

[kamstra]

Ik zou er eerder voor pleiten om gewoon die 1k berichtengrens weer overal in te voeren. Blijft het mooi overzichtelijk van, en wat heeft t voor zin om in een topic van 6k berichten te gaan graven. Daarbij kan je als je een succesvolle reeks hebt van een topic mooi elke 1k posts de startpost aanpassen, zodat ie lekker actueel blijft

[disjfa]

Ik zou het bij topics waar een goede ts bij nodig is zo instellen dat er een nieuw topic komt als het handig is de oude te upgraden. De 1000 post grens is lomp en onnodig imho bij veel topics.

Meer of minder gelieve de inhoud van het topic lijkt me veel beter.

[crisp]

Dancing_Animal schreef op zondag 06 mei 2007 @ 20:35:
[...]
Ik vraag me trouwens ook af of de breedte van de topics niet groter kan. Kun je ook veel overzichtelijkere tabellen maken. Ik denk niet dat er veel mensen zijn die nog op 800x600 draaien.

Lange zinnen lezen minder makkelijk omdat je dan moeilijker het begin van de volgende regel kan vinden.

[SmartDoDo]

Jk_W schreef op zondag 06 mei 2007 @ 20:03:
Bij veel topics is het handig om een nieuw deel te openen, zodat de topicstart geupdate kan worden, maar bij veel topics is het echter totaal nutteloos geworden. Een voorbeeld is bijvoorbeeld het "heb je iets nieuws en je moet het gewoon showen" topic. Ik zie hierbij geen reden om een nieuw topic te openen om de 1000 posts.

Ik denk dat je op zich ook wel gelijk hebt met het topic wat je nu aanhaalt. Bij andere topics kan het veelal geen kwaad met een fris nieuw topic te beginnen.

Wat me wel tegenstaat aan hele grote topics is het beeld wat er vanuit gaat: opsomtopics. En hoewel het door jou aangehaalde topic in essentie niets anders is dan het patsen/laten zien van nieuw aangeschafte zut, zie ik daar liever toch met regelmaat een nieuw topic voor komen.

Men is nu gewend aan "1000 posts, nieuw topic" en wat mij betreft houden we dat in principe ook zo. Neemt niet weg dat er hier en daar topics zijn waarbij daar best van afgeweken kan worden. Voorbeeld is Het algemeen horloge topic, deel 3 waarbij er simpelweg geen nieuw topic is aangemaakt en er ook geen noodzaak is het huidige topic te sluiten

[JHS]

Jk_W: Alhoewel je volgens mij goed onderbouwd dat het in veel gevallen niet zinnig is om een nieuw topic te openen, mis ik een reden om de policy te veranderen . Het sluiten van die topics kan volgens mij weinig kwaad, het is consistent op deze manier, en dat er geen technische reden meer is om ze te sluiten wil denk ik niet zeggen dat we het dus maar niet meer moeten doen.

[Motrax]

krvabo schreef op zondag 06 mei 2007 @ 20:35:
[...]

De query moet wel alle records doorlopen, en daarna de eerste 50 pakken
Dus ja, het is trager.. al is het verschil tussen het weergeven van:
= de eerste 50 posts uit een topic met 100 posts
= de eerste 50 posts uit een topic met 500 posts
Niet extreem veel langzamer, of zelfs nauwelijks.

Serieus? Waarom pakt ie dan niet gewoon de 1e 50, zonder de rest te lezen? Of 51-100, waarbij 1-50 en 101-xxx overgeslagen wordt?

[Resistor]

Het ligt helemaal aan het soort topic.

Het 'heb je wat nieuws' topic mag van mij rustig doorlopen tot 10.000 posts, omdat het meestal maar losse berichtjes zijn.
Maar bij voorbeeld het 'Nokia N95 topic' mag van mij wel ophouden bij 500 posts, en dan weer een nieuw topic met verse informatie in de startpost.

[krvabo]

Motrax schreef op zondag 06 mei 2007 @ 21:12:
[...]
Serieus? Waarom pakt ie dan niet gewoon de 1e 50, zonder de rest te lezen? Of 51-100, waarbij 1-50 en 101-xxx overgeslagen wordt?

Ach, het ligt er ook aan waar er indexes worden gelegd.

id | uid | topicid
2  |  4   |  4
3  |  9   |  4
4  |  11  |  4
5  |  4   |  5

Dan doorloopt ie elk record om te kijken welk record topicid 4 heeft. In principe kan ie er na 50 records wel mee ophouden, maar je query bevat bij fora ook nog een 'ORDER BY datum'. Dan selecteert de db eerst alle records met topicid 4, gaat ze dan sorteren, en pakt dan de eerste 50.

[ Voor 22% gewijzigd door krvabo op 06-05-2007 21:19 ]

[Verwijderd]

Ik vind het wel fijner als bij 1000 posts er een nieuw topic komt. Het is overzichtelijker. En buiten dat zit je anders met al die oude berichten opgescheept.

[Motrax]

offtopic:
Ah ja zo... ik was er eigenlijk van uit gegaan dat elk topic een nieuwe tabel was
Tnx krvabo

[Zoefff]

Apen-nootjes schreef op zondag 06 mei 2007 @ 20:26:
[...]

Bij veel, heel veel replies is dat nog steeds zo

Afaik zijn er een aantal optimalisaties doorgevoerd waardoor dat niet meer zo is

[moto-moi]

Zoefff schreef op maandag 07 mei 2007 @ 23:58:
[...]

Afaik zijn er een aantal optimalisaties doorgevoerd waardoor dat niet meer zo is

..die wij nog niet getest hebben en dus nog niet @ productie draaien

[eamelink]

silverstorm schreef op zondag 06 mei 2007 @ 20:06:
2) het is nogal vervelend om een topic te zien waarin je 2 jaar geleden hebt gereageerd en deze steeds in je posthistory naar boven geschopt te zien.

Dat lijkt me eigenlijk veruit de belangrijkste reden

[.oisyn]

krvabo schreef op zondag 06 mei 2007 @ 21:18:
[...]

Ach, het ligt er ook aan waar er indexes worden gelegd.

id | uid | topicid
2  |  4   |  4
3  |  9   |  4
4  |  11  |  4
5  |  4   |  5

Dan doorloopt ie elk record om te kijken welk record topicid 4 heeft.

Maar dus niet als er een juiste index op staat

In principe kan ie er na 50 records wel mee ophouden, maar je query bevat bij fora ook nog een 'ORDER BY datum'. Dan selecteert de db eerst alle records met topicid 4, gaat ze dan sorteren, en pakt dan de eerste 50.

Maar dus niet als er een juiste index op staat

[CLB]

Resistor schreef op zondag 06 mei 2007 @ 21:15:
Maar bij voorbeeld het 'Nokia N95 topic' mag van mij wel ophouden bij 500 posts, en dan weer een nieuw topic met verse informatie in de startpost.

Just my thougts! Dat topic heeft nu 2716 posts terwijl andere topics in PSGG tot 1000 mogen lopen..

[cryforhelp]

eamelink schreef op dinsdag 08 mei 2007 @ 00:26:
[...]


Dat lijkt me eigenlijk veruit de belangrijkste reden

Helemaal mee eens, van die antieke topics die je maar niet uit je posthistory krijgt zijn ontzettend irritant. Soms heb je het na 2 jaar gewoon niet meer met een bepaald onderwerp. Ik ben dan ook blij dat ik niet per ongeluk een keer in het bekenden koningsplein topic heb gepost, dat ding is 2 (3?) jaar oud en blíjft maar terugkomen.

Datzelfde geldt trouwens ook voor topics die gewoon elke maand geschopt worden, maar waar weinig in gepost wordt.

Misschien dat er gewoon op een gegeven moment besloten moet worden dat het tijd is voor een nieuw topic. Dus dat topics die baten bij een verse startpost en met een lage doorlooptijd na weinig posts dichtgaan. En onschuldige blaattopics na 1000 of 2000 posts. Ik blíjf er voorstander van om topics niet oneindig door te laten gaan, het is gewoon irritant als user.

[Spider.007]

krvabo schreef op zondag 06 mei 2007 @ 20:35:
[...]

De query moet wel alle records doorlopen, en daarna de eerste 50 pakken
Dus ja, het is trager.. al is het verschil tussen het weergeven van:
= de eerste 50 posts uit een topic met 100 posts
= de eerste 50 posts uit een topic met 500 posts
Niet extreem veel langzamer, of zelfs nauwelijks.

Dat is natuurlijk niet waar. De eerste posts zijn het probleem niet. Het gaat om de laatste 50 posts; die zijn veel interessanter en daarmee gaat mysql rustig op zijn bek als hij uit een topic van 50.000 berichten de laatste 50 moet vissen. In React 1.9.5 hebben we dit uiterst inventief afgevangen maar de kans dat dat op GoT gaat draaien is erg klein; ik gok dat het een uur of 2 duurt voordat de initiële wijzigingen in de database zijn doorgevoerd

cryforhelp schreef op dinsdag 08 mei 2007 @ 02:00:
[...]

Helemaal mee eens, van die antieke topics die je maar niet uit je posthistory krijgt zijn ontzettend irritant. Soms heb je het na 2 jaar gewoon niet meer met een bepaald onderwerp. Ik ben dan ook blij dat ik niet per ongeluk een keer in het bekenden koningsplein topic heb gepost, dat ding is 2 (3?) jaar oud en blíjft maar terugkomen.

[...]

Hier is in React 1.9.5 ook een leuke feature voor bijgebakken; de mogelijk om items uit je posthistory te verbergen

[ Voor 25% gewijzigd door Spider.007 op 08-05-2007 08:03 ]

[cryforhelp]

Spider.007 schreef op dinsdag 08 mei 2007 @ 08:02:
[...]

Hier is in React 1.9.5 ook een leuke feature voor bijgebakken; de mogelijk om items uit je posthistory te verbergen

Ah, relaxed
Ik kreeg van het vorige feature request topic de indruk dat dat niet zou komen, maar mooi dat het erin zit.
In dat geval lijkt het me prima om topics lang open te laten

[silverstorm]

Spider.007 schreef op dinsdag 08 mei 2007 @ 08:02:
In React 1.9.5 hebben we dit uiterst inventief afgevangen maar de kans dat dat op GoT gaat draaien is erg klein; ik gok dat het een uur of 2 duurt voordat de initiële wijzigingen in de database zijn doorgevoerd

Wat is nu 2 uur als je er daarna enorm veel preformancewinst mee haalt?

Hier is in React 1.9.5 ook een leuke feature voor bijgebakken; de mogelijk om items uit je posthistory te verbergen

Is het dan de bedoeling dat je voor elk topic appart moet aangeven of je het wil laten zien in je posthistory?

[Voutloos]

silverstorm schreef op dinsdag 08 mei 2007 @ 12:42:
Is het dan de bedoeling dat je voor elk topic appart moet aangeven of je het wil laten zien in je posthistory?

De mogelijkheid om te verbergen, niet de mogelijkheid om alles aan je history toe te moeten voegen.

[Spider.007]

silverstorm schreef op dinsdag 08 mei 2007 @ 12:42:
[...]

Wat is nu 2 uur als je er daarna enorm veel preformancewinst mee haalt?

En wat is 2 uur voor een feature die hier helemaal niet aangezet gaat worden?

[Rafe]

Spider.007 schreef op dinsdag 08 mei 2007 @ 08:02:
In React 1.9.5 hebben we dit uiterst inventief afgevangen maar de kans dat dat op GoT gaat draaien is erg klein; ik gok dat het een uur of 2 duurt voordat de initiële wijzigingen in de database zijn doorgevoerd

Kan ik hieruit opmaken dat versie 2.0.0 dusdanig ver is ontwikkeld dat die tussenstap niet nodig is?

[Spider.007]

Rafe schreef op woensdag 09 mei 2007 @ 11:11:
[...]

Kan ik hieruit opmaken dat versie 2.0.0 dusdanig ver is ontwikkeld dat die tussenstap niet nodig is?

React 2 wordt een complete rewrite vanaf scratch en ondanks dat we daar inderdaad erg veel vooruitgang mee boeken moet er ook nog flink veel geschreven worden voordat daar React-forum op gaat draaien Ik denk dat de 1.9.5 tussenstap dus wel degelijk nodig zal zijn als we op GoT dit soort nieuwe features willen implementeren

[.oisyn]

Spider.007 schreef op dinsdag 08 mei 2007 @ 08:02:
[...]

Dat is natuurlijk niet waar. De eerste posts zijn het probleem niet. Het gaat om de laatste 50 posts; die zijn veel interessanter en daarmee gaat mysql rustig op zijn bek als hij uit een topic van 50.000 berichten de laatste 50 moet vissen. In React 1.9.5 hebben we dit uiterst inventief afgevangen

Als je gewoon omgekeerd sorteert ben je er waarschijnlijk ook. Dan verplaats je het probleem weliswaar, maar de laatste pagina wordt natuurlijk vaker opgeroepen dan de eerste. Bovendien zou je de sorteerrichting af kunnen laten hangen van welke pagina er opgeroepen wordt (dan is alleen het midden nog langzaam). Of was dat juist die inventieve feature?

[Spider.007]

.oisyn schreef op woensdag 09 mei 2007 @ 12:15:
[...]


Als je gewoon omgekeerd sorteert ben je er waarschijnlijk ook. Dan verplaats je het probleem weliswaar, maar de laatste pagina wordt natuurlijk vaker opgeroepen dan de eerste. Bovendien zou je de sorteerrichting af kunnen laten hangen van welke pagina er opgeroepen wordt (dan is alleen het midden nog langzaam). Of was dat juist die inventieve feature?

Nope, we hebben het nu op een andere manier opgelost. Geforceerd omgekeerd zou ook kunnen; maar lijkt me als user nogal een vervelende feature aangezien je preferences dan ineens worden genegeerd.

[PromWarMachine]

Het enige voordeel dat ik zie is dat je met 1 gigantisch topic (bij World of Warcraft zou dat gaan om ~120k replies btw ) is dat het zoeken een stuk aangenamer wordt.
In de praktijk zie je dat mensen best de moeite willen nemen om te zoeken, maar daarbij niet alle vorige delen door willen lopen.

Daarom zou ik liever iets zien waardoor je topics over 1 onderwerp als het ware kan koppelen, zodat er bij een searchquery in deel 1 ook gezocht wordt in deel 2, deel 3 en alle andere delen tot het laatste deel waar men nu in bezig is.

Overigens zal het merendeel van de gebruikers het aantal_replies op default hebben staan. Is dat nog steeds 25? Stel dat je dan een topic hebt met 5000 replies dan wil je dat niet zien in je active topics lijst

[.oisyn]

Spider.007 schreef op woensdag 09 mei 2007 @ 12:40:
[...]

Nope, we hebben het nu op een andere manier opgelost. Geforceerd omgekeerd zou ook kunnen; maar lijkt me als user nogal een vervelende feature aangezien je preferences dan ineens worden genegeerd.

Onzin natuurlijk, hoe de data uit de db komt heeft in feite niets te maken met hoe die data uiteindelijk gepresenteerd wordt. En een array van pakweg 50 posts omdraaien in PHP gaat wel een stukje sneller dan de achterste 50 posts uit een 50000 posts tellend topic vissen

[Morax]

.oisyn schreef op dinsdag 08 mei 2007 @ 01:18:
[...]

Maar dus niet als er een juiste index op staat


[...]

Maar dus niet als er een juiste index op staat

Dan ben ik toch wel benieuwd hoe die DB dan de nieuwste 50 posts selecteerd, zonder te kijken naar de datum van de rest van de posts? (Niet om je onderuit te halen, maar ik kan het me niet voorstellen)

[Voutloos]

Lekker offtopic allemaal. De inventieve feature werkt dus niet puur dmv een index in omgekeerde volgorde en is ook snel in het midden van een grooot topic.

[.oisyn]

Morax schreef op woensdag 09 mei 2007 @ 14:37:

Dan ben ik toch wel benieuwd hoe die DB dan de nieuwste 50 posts selecteerd, zonder te kijken naar de datum van de rest van de posts? (Niet om je onderuit te halen, maar ik kan het me niet voorstellen)

Een index betekent impliciet een volgorde (anders valt er weinig te doorzoeken). Als je dus een index hebt op topic_id en vervolgens op de posttijd (of gewoon de post_id als je er gemakshalve even vanuit gaat dat een post met een hoger id altijd op een later moment gepost is), dan hoeft er dus niet meer gesorteerd te worden en kan de db simpelweg de eerste (of laatste) 50 uit de index halen.

[Voutloos]

• LIMIT 10000, 25 is niet zo snel als het klinkt
• Er is niet zoiets als een DESC index in mysql, DESC mag wel opgegeven worden, maar wordt genegeerd.
• Meerdere indexen op exact dezelfde kolommen zou ook niet ideaal zijn, zowel qua opslag als qua performance in het midden ve topic.
• Lekker offtopic.
• Geef nou maar gewoon toe dat je wil weten wat de inventieve feature wel doet.

[.oisyn]

[quote]Voutloos schreef op woensdag 09 mei 2007 @ 15:20:
• LIMIT 10000, 25 is niet zo snel als het klinkt
Dat is idd de hele issue hier, heel goed
[q]• Er is niet zoiets als een DESC index in mysql, DESC mag wel opgegeven worden, maar wordt genegeerd.
Ik heb het niet over mysql maar in het algemeen, en het doet er niet toe welke kant de index op "wijst". Het gaat erom dat je er range queries op kunt doen in O(log N + K) tijd, daar is ie voor. Daarbij maakt het niet uit of je de eerste K, laatste K of middelste K wilt hebben. De implicatie is echter dat je niet weet van waar tot waar pagina x loopt, en je dus geen query kunt maken voor de middelste K anders dan de eerste x*K posts aflopen en daar de laaste K van pakken.

[q]• Meerdere indexen op exact dezelfde kolommen zou ook niet ideaal zijn, zowel qua opslag als qua performance in het midden ve topic.
Dat hangt van je usecases af, maar als je iets altijd gesorteerd terug wil hebben, en je hebt vele malen meer read dan writes, dan is een index nuttig, omdat de update-kosten in het totaalplaatje lager zijn dan de sorteer-kosten.

[q]• Lekker offtopic.
Hou je mond dan. Als jij het offtopic vind moet je zelf ook niet op het verhaal verder gaan. Als je er wel op verder gaat moet je ook niet zeuren dat het offtopic is. Ik klink wellicht wat geergerd, maar dit is al de tweede keer dat je dat zegt terwijl je wel gewoon doodleuk meedoet met de discussie.

• Geef nou maar gewoon toe dat je wil weten wat de inventieve feature wel doet.

Nee het kan me weinig schelen. Morax wilde weten hoe dat met een index moet werken, dat leg ik uit.

[ Voor 9% gewijzigd door .oisyn op 09-05-2007 15:34 ]

[RoD]

Ik lees hier een aantal keren het argument dat een topic gesloten wordt zodat de TS vernieuwd kan worden met nieuwe informatie enzo...

... Worden topicstarts dan niet gewoon netjes bijgehouden? Imo, als je een groot topic start, moet je ook de verantwoordelijkheid nemen om het allemaal netjes bij te houden. Ik hou zelf al "mijn" topics goed bij met een changelog ed, dus wat dat betreft is er (puur op dat argument) imo geen reden om topics te sluiten.

[JHS]

RoD: Natuurlijk is dat idealiter zo, maar het kan natuurlijk dat een topicstarter geen tijd meer heeft, of dat 'ie niet voorzien had dat het zoveel tijd zou kosten, of dat het überhaupt niet voorzien was dat het een groot topic zou worden. Daarnaast zie ik nog steeds geen reden om ze níet te sluiten - terwijl er al wel een aantal redenen gegeven zijn om dat wel te doen .

[RoD]

Indien een TS geen tijd/zin meer heeft kan er natuurlijk een nieuwe TS komen, dat gebeurd afaik ook wel. Verder ging het mij puur om dat argument. Ik ben het met je eens dat er redenen zijn om ze wel bij 1000 posts te sluiten en ik vind dat persoonlijk ook wel het prettigst.