Autor Zpráva
Kcko
Profil
Ahoj,

mám jednu funkční diskusi (stromová, ajaxová s mnoha featurami , kdy jednou z nich je označení nových komentářů = tj. ty které jsem jako registrovaný uživatel nečetl, jsou odlišeny barvou).

Je to řešeno vazební tabulkou do které si poznačuji uživatele a čas navštívení konkrétního topicu (ve kterém jsou ony komentáře).
To bylo dlouho dostačující.

Nyní se bude muset diskuse stránkovat a s tím přišel samozřejmě problém.

Příklad:

Mám na diskusi 60 komentářů, stránkováno po 20-ti. Tj 3 stránky.
Ještě jsem daný topic nenavštívil.

Vlezu tam, uvidím komentáře 60-40 (1 strana), jako nové, kliknu na stranu 2 (40-20) a v tu chvíli už tyto další komentáře nové nejsou, protože se mezitím přeuložil čas navštívení topicu.

Jediné co mě napadá ukládat vazbu
komentář | user | přecteno (ano|ne).

A pak to obslouží i stránkování.

Má to nevýhodu, že data v tabulce comments_read budou hrozně rychle růst.

Nemá někdo datově úspornější řešení? díky.
Tomášeek
Profil
Kcko:
Nestačilo by stará (třeba 6 měsíců, 12 měsíců) data v té tabulce mazat a staré příspěvky dle data přidání považovat automaticky za přečtené? Tzn. indikace nepřečtenosti by byla jen u "nových" příspěvků, tedy mladších 6, 12, ... měsíců.

Není to ideální, ale myslím, že to je řešení, které by ve většině případů mohlo být průchozí. Pokud ne, tak se samozřejmě rychle rostoucímu počtu záznamů nevyhneš.
Kajman
Profil
Když se stránkuje, tak se rozdělí vlákno i uvnitř nebo se dělí jen před příspěvkem, co není zanořen?

Když se chce uživatel mrknout na všechny nepřečtené, musí proklikat všechny stránky, nebo se to přečtené zabalí.

Je možné detail přečtenosti držet jen na jednom zařízení v localstorage?
Keeehi
Profil
Je možné detail přečtenosti držet jen na jednom zařízení v localstorage?
Pokud je pro tebe problém si držet čtení topicu na úrovni příspěvků tak osobně se mi líbí tato varianta kombinovaná s aktuálním přístupem. Pořád si držet v databázi přečtenost/nepřečtenost topicu v případě že se uživatel přihlásí jinde/promaže si prohlížeč. A rozlišní na příspěvky mít uložené až u uživatele.

Ten nárůst ale nemusí být tak velký. Záleží případ od případu ale zdejší diskuse stránkuje po třiceti příspěvcích a na druhou stránku se dostaneme málokdy. I kdybychom se na druhou stránku dostali pokaždé, tak to znamená jen dvojnásobný nárůst oproti počítání návštěvnosti po celém topicu bez stránkování.
Kajman
Profil
Keeehi:
tak to znamená jen dvojnásobný nárůst

To je fakt, zpětně to půjde zrekonstruovat (pokud se příspěvky nebudou mazat, ale bude u nic čas "smazání"). Tohle úsporné řešení by bylo náročnější na výpočet nepřečtených, ale kdyby se dělalo jen ve chvíli zobrazení 1 vlákna, tak bych se toho určitě nebál.

Pokud by nebyly všechny časy všech stránek větší než čas posledního příspěvku, tak by se asi muselo pro každou stránku a její navštívený čas sestavit odpovídající strom, z něho vzít příspěvky, co v tu chvíli byly na dané stránce.

V přehledu vláken by se to muselo počítat pro všechna zobrazená vlákna, co se nevejdou na jednu stránku. To by se muselo otestovat, zda to server zvládne.
Kcko
Profil
Tomášeek:
Zajímává idea, možná by to šlo, nechám si to až jako jako nouzovku.

Kajman:
Localstorage určitě ne, musí to být vázané na uživatelský účet a na DB, protože ostatně i já přistupuji k webu z vícerozařízení (notebook, telefon, občas tablet a hodně uživatelů to bude mít podobně.

Když se stránkuje, tak se rozdělí vlákno i uvnitř nebo se dělí jen před příspěvkem, co není zanořen?
Vzhledem k tomu, že tam bude hodně příspěvků a hodně uživatelů, tak to řeším tak, že jsou reálně stránkovány jen příspěvky první úrovně (tj rodičovské), u nich zobrazuji informaci, kolik mají reakcí, a po tlačítku na zobrazit reakce ony reakce (uzel s dětmi) donačítám ajaxem.

Takže to stránkování se týká jen rodičovských příspěvků, takže na stránce klidně může být 100 komentářů a ne 30.

Keeehi:
Nárůst bude docela vysoký, cca 300k - 1M / měsíc.
LocalStorage ne, to se mi nelíbí, chci to mít v DB a nechci aby to bylo vázano na konkrétní prohlížeč. Klient není zcela bystrý, resp. nechci ho urazit, ale nějaké věci se mu špatně vysvětlují a já na nemám sílu mu tohle vysvětlovat, proč to funguje takhle atd.

Kajman
To je fakt, zpětně to půjde zrekonstruovat (pokud se příspěvky nebudou mazat, ale bude u nic čas "smazání"). Tohle úsporné řešení by bylo náročnější na výpočet nepřečtených, ale kdyby se dělalo jen ve chvíli zobrazení 1 vlákna, tak bych se toho určitě nebál.
>
Pokud by nebyly všechny časy všech stránek větší než čas posledního příspěvku, tak by se asi muselo pro každou stránku a její navštívený čas sestavit odpovídající strom, z něho vzít příspěvky, co v tu chvíli byly na dané stránce.
>
V přehledu vláken by se to muselo počítat pro všechna zobrazená vlákna, co se nevejdou na jednu stránku. To by se muselo otestovat, zda to server zvládne.


Mno, už se mi do ničeho razantního nechce. Diskusi mám téměř hotovou, otestovaná nad 2M příspěvky a je to hezky rychlé.


Takže pro mě závěrem:

1) Klientovi vysvětlím a bude muset zkousnout, že se mu ta informace o nových příspěvcích holt po dalších klicích na pager ztratí
2) Předělám to na vazbu (user_id | post_id | seen (=1))
3) 3ka + návrh od Tomášeek, akorát si interval zkrátím ne na 6-12 měsíců, ale třeba jen na posledních 30dní.

Budget není nafukovací, limity hostingu jsou jasně dané a já nejsem kouzelník (i tak tomu přidávám větší užitnou hodnotu než bych musel).

Díky pánové.
Kajman
Profil
Stránkování po rodičovských příspěvcích sice zjednodušuje případnou práci s Keeehiho variatou
userid, vlaknoid, stranka, cas
Ale tím, že se reakční příspěvky zobrazí až po rozkliknutí, tak se to celé komplikuje a bez struktury
userid, postid(jen příspěvky bez rodiče), cas (bez rozkliknutí čas zakladního příspěkvu, po rozkliknutí systémový čas)
to asi nepůjde. Ale zase se nemusí ukládat všechny posty, pokud se zobrazují všechny rekace nebo žádná.
Kcko
Profil
Kajman:
Ano máš pravdu.
U rodičů se musí ID ukládat a u reakcí; jelikož jsou načítané ajaxem stačí uložit jejich rodiče a čas posledního navštívení (tj. ne všechny ID dětí), tím by se docela dost ušetřilo :-).

V tomto případě je to stránkování trošku na škodu :-) a udělalo dost problémů.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0