~~(  Ɛ8>× ×<83  )~~
BÍLÉ MYŠI
Hledat Seznam doupat REGISTRACE
LOGIN:
HESLO:
ÚVOD REGISTRACE VŠECHNA DOUPATA
LOGIN: HESLO:
LOGIN:
HESLO:
REGISTRACE
;

     

Nadpis:Nadpis:
Obsah:Obsah:
   

Píďa 😜 (PetaKlic) ve škole nám pořád říkali - že jednou vyrosteme. nekecali. asi by se tu ohla držet debata na odbornější úrovni
rionka nenasimulovatelná anomálie (teď mě vlastně napadlo, že smazáním takového objemu času bychom se mohli na myších vratit do středověkého období a možná býti svědkem vynálezu knihtisku) (ne, nebudu to zkúšat)
rionka nenasimulovatelná anomálie objem nahraných videí na YouTube již několikrát překročil počet hodin, vyjadřující dobu, jak dlouho máme na světě internet, a zvyšuje se exponenciálně každým dnem
Einy 🐺 Trápí vás samota? - Staňte se schizofrenikem! Balo bych se, co udela MamSQjeLe s takovym objemem smazaneho casu.
rionka nemá přece smysl posílat - prázdný příspěvek kdybych nečet šecky vaše kydaty, ušetřím ročně 74937 let
rionka nemá přece smysl posílat - prázdný příspěvek no, to sem rád že si tento drobný fakt uvědomují, spanembohem
Píďa 😜 (PetaKlic) ve škole nám pořád říkali - že jednou vyrosteme. nekecali. žiš, něžná narážka, ne? bez tolika smazanejch nejnovějších by odhalení té chyby trvalo 12× déle
rionka nemá přece smysl posílat - prázdný příspěvek zrionkuju pdp, laskavě


technologie si postavili a lezli jim do toho, psali, testovali! vopruz, co?

Píďa 😜 (PetaKlic) ve škole nám pořád říkali - že jednou vyrosteme. nekecali. problém s innodb a neodnovikovatelnými noviky

letitá záhada s visejícími noviky vyřešena

jak chyba vznikla

za normálních okolností si MySQL pamatuje tzv. auto increment, tedy jaké ID má dostat další příspěvek.

takže pokud něco napíšu, dostane to nějaké ID, třeba 5, a MySQL si pamatuje, e další ID má být 6.

pokud ID 5 zrionkuju smažu, pořád si MySQL pamatuje, že další má být 6.

problém nastane ve chvíli, kdy se z nějakého důvodu restartuje služba MySQL na serveru, kvůli chybě (možná to má být featura, že šetří pár byte na disku, nevím) v databázovém enginu InnoDB se autoinkrementy ztratí a znovu se dopočítají podle posledního existujícího postu.

tato, říkejme tomu vlastnost, není všeobecně známa, tudíž se na ni nedá při návrhu programu myslet, natož ji jednoduše odhalit.

===

pozadí chyby:

aby uživatel mohl být upozorněn na nový příspěvek, musí si pamatovat, který naposledy viděl. on naposledy viděl 5, ještě předtím, než byl smazán. kdyby někdo napsal nový s číslem 6, nic by se nedělo, pokud by mezi tím nedošlo k restartu MySQL a zapomenutí, že další má být 6.

takže se uloží nový příspěvek s číslem 5, nebo v horším případě třeba 4 i nižší, pokud by bylo smazáno víc příspěvků.

pokud by byl uživatel informován o novikách na základě ID, ani by nedostal zprávu, že tam nějaký nový je

JENŽE

v rámci optimalizace se noviky nepočítají podle ID, protože by to zabralo kopec databázového času (procházení všech tabulek).

seznam všech diskuzí má pro každou hodnoty "total" a "smaz".

Do totalu se ukládá informace o tom, kolik příspěvků je kde celkem, do smaz se ukládá, kolik jich bylo za celou historii smazáno.

stejné hodnoty si pamatuje každý uživatel, navíc ještě "novik".

při načtení seznamu se děje toto:
- načte se seznam všech diskuzí, kde se kdy jaký uživatel nacházel
- ze seznamu všech existujících diskuzí se načtou ty stejné
- pokud se rozchází "total", rozdíl se přičte k "novik"
- pokud se rozchází "smaz", daná diskuze se přepočítá podle ID (tím se myši vyhýbají okouní chybě s rozbitím počítání po smazání)
- pokud je "total" nastaven na 0, přepočítá se rovněž podle ID (total je 0 vždy po odnovení, aby se to dopočítalo znovu správně, nebo po stisknutí kouzelného debugovacího tlačítka, které mělo tuto chybu řešit)
- při přepočítání se v uživatelské tabulce zapamatuje správný total, správný smaz a správný novik

při vlezení do doupěte se děje toto:
- načte se příslušný počet příspěvků (i v závislosti na odstránkování)
- příspěvky, které mají vyšší ID, dostanou třídu "novy post", aby na uživatele "svítily" jinými barvičkami (dle skinu)
- zároveň se uloží nejnovější zobrazené ID do proměnné
- pokud je nejnovější zobrazené ID větší, než to, které si pamatuju, nachystá se ajax request pro odnovení (ajaxem se odnovuje z bezpečnostních důvodů)

no a naše chyba způsobí toto:
- uživatel je SPRÁVNĚ upozorněn na nečtené příspěvky (rozdíl v totalech)
- uživael si je vleze přečíst
- nové příspěvky, které nemají vyšší ID než zapamatované se správně neobarví
- pokud ani ten úplně nejnovější nemá vyšší ID, než ono zapamatované, nedojde k odnovení, nedojde k vynulování totalu a informace o nečtených zůstane viset.

===

řešení chyby, která je na straně využívané služby, je nemazat příspěvky doopravdy, ale jen je označit jako smazané (konkrétně se to děje vymazáním sloupečku "login") a při načítání z databáze je vynechat.

tím se zachová poslední vložené ID a při restartu MySQL služby se podle tohoto správně dopočítá auto_increment.

aby úzkostliví uživatelé neměli strach, že v databázi visí něco, co nechtějí, aby někde viselo, hned po tomto označení jsou skutečně fyzicky vymazány všechny záznamy, s výjimkou toho, jehož ID odpovídá poslednímu vloženému.

i tento se však nakonec smaže, s nejbližším dalším mazáním.

možná mě rostoucí gdpr šílenosti časem doženou k tomu, že kromě sloupečku login vymažu úplně všechny, kromě ID.

chyba by tak měla být zažehnána.

Píďa 😜 (PetaKlic) (tlustá bestie) komiksy Modré myši
není svět růžový a nejde všechno tak, jak bychom si přáli, proto bylo nutné se vypořádat s nějakými komplikacemi.....

1) opráski

stahování RSS přímo z webu https://www.tumblr.com/ není možné, protože tumblr nasadil GDPR a uživatel musí potvrdit, že tam opravdu chce, než dostane data, to platí i pro RSS soubor, takže nejde stáhnout skriptem, ani když se požadavku podstrčí cookie o tom, že tam opravdu chci

druhý web na ráně je https://twitter.com/ a RSS je zprostředkován webem https://rss.app/. zatím nezbývá, než doufat, že je tento generátor RSS nějak rozumně funkční a nebudu muset luštit zdroják twitteru.

problém je, že některé prohlížeče (firefox v anonymním režimu, o jiných zatím nevím) blokují obrázky z twitteru, protože mohou obsahovat sledovací prvky; pokud by se vyskytl problém se zobrazením oprásků, budou se muset reuploadovat...

2) garfield

garfield už nějakej ten pátek používá stejný formát názvu souboru kdesi na cloudu, stačí se tedy zeptat, zda soubor s dnešním datem již existuje pomocí exif_imagetype.

3) dilbert

stahujeme přímo z webu https://dilbert.com/, stačí porovnat adresu aktuálního obrázku s poslední použitou.

4) dilbert CZ

úplně stejně, ae z webu https://www.idnes.cz/

Píďa 😜 (PetaKlic) Autor většiny bugů. FILOVA ZÁHADA
při prvním vlezení do doupěte se udělá záznam, že tam člověk vlezl A nastaví se mu poslední nečtený (a pokud tam nic není - třeba i proto, že tam nesmí číst) na číslo 0. tím se stalo doupě navštíveným.

Pokud ovšem doupě booknu (což udělal Fila), poslední nečtený se nenastaví >> je tam hodnota NULL a při následném vlezení do takového doupěte nedojde k aktualizaci noviků, prostě proto, že pokud je výsledek odnovovátka číslo 0, tak se nezapíše (ajaxí podmínka, že má odnovit, pozná podle toho, že hodnota >0).

každopádně - existencí záznamu, který vznikl booknutím, se počítají noviki.

tedy, bude se muset pro tento případ vynaleznout výjimka.

Píďa 😜 (PetaKlic) Autor většiny bugů. Pozadí bugu s nečtenými

každé doupě si ukládá počet příspěvků a počet smazaných, aby se nemuselo při načtení seznamu počítat (což by časem trvalo jako kráva)

každý uživatel si pak pamatuje
- id posledního přečteného
- o kolika příspěvcích v doupěti ví
- o kolika nečtených ví
- o kolika smazaných ví

pokud vlezu do seznamu, tak ABYCH NEMUSEL znovu každému počítat nečtené, zjistím
- pokud se rozchází celkový počet, který si pamatuje uživatel, od celkového v doupěti, pouze se přičte rozdíl
- pokud se rozchází počet smazaných, přepočítají se noviky znovu, protože se neví, jestli se smazalo něco, co jsem četl, nebo ne (proto to nedělá lopuchookouní chybu)
- pokud si NEPAMATUJU celkový počet, přepočí tá se to

při návštěvě doupěte se pak VŽDY nastaví poslední přečtený a ODPAMATUJE se uživatelský celkový tak, aby se nečtené spočítaly znovu (pokud je jich víc

pokud mám doupě v sidebaru, tak se to přepočítá, pokud ho tam ale nemám, tak se mi to nepřepočítá (dokud nenavštívím seznam)

no a při odpovědi se doposud dělo to, že jsem k tomu uživatelsky zapamatovanému počtu přičetl jedničku, abych si ušetřil přepočítávání, JENŽE - s ODPAMATOVÁNÍM při návštěvě a NEPŘEPOČÍTÁNÍ sidebarem si to myslelo, že vím o jednom a rozdíl přičetlo.

nyní tedy odpověď na nový příspěvek NULUJE to pamatování a přepočítává se to znovu (správně)

Píďa 😜 (PetaKlic) Autor většiny bugů. navazuji na https://bilemysi.cz/doupata.php?doupe=navrhy&vlakno=580

(nevím, podle mě jsou upload od usera, tzn to, co se nahraje POSTem od usera do $_FILES, a file_get_contents, který umí načíst cokoliv odkudkoliv, dvě rozdílné věci, ale nedokážu se nikde dočíst ve specifikacích, jestli se tahle php.iniovina dotýká práce s file_get_contents)

každopádně je zbytečné to řešit, protože použitý exif_imagetype by si měl stáhnout - podle specifikace - jen pár byte, a to, co zdržuje, je hledání konektivity pro ten přenos těch pár byte, protože každá adresa mi poprvý leze dýl a podruhý to jen mrkne (pokud to není zmíněný příklad s okouním hackem, kdy - než vzdálená url vrátí aspoň nějaká data, protože pracně žvejká výstup mysqli query o pár tisících řádků - prostě ten exif čeká na odpověď)

asi zkusím to, že si udělám sobě výjimku vázanou na můj login a vyzkouším, jak se to bude chovat - localhost se často chová všelijak jinak, než potom velkej server






 Bílé myši (c) 2018, 2019 Strašlivý Píďa.   Webhosting ZONER software, a.s.   https://www.czechia.com/ 
 Stránky používají cookies.   Bez nich to nejde.   BUBUBU! JSME ZLÉ COOKIES!   Nesouhlasíš-li s použitím cookies, táhni. 
čeká se na ajax