jeste jednou k database cache
- David Matějka
- Moderator | 6445
ted jsem si overoval moje podezreni na ne uplne spravne chovani
nette\database accesed cache a potvrdilo se. accessed cache slouzi k tomu, aby
se nepristupovalo ke sloupeckum, ktere se nepouziji. jako klic cache se pouziva
nazev tridy, nazev tabulky a podminky dotazu.
nyni si predstavme nasledujici kod:
<?php
foreach($database->table("book") as $book){
echo "<h1>" . $book->name . "</h1>";
}
foreach($database->table("book") as $book){
echo "<p>" . $book->description . "</p>";
}
?>
(ty foreache muzou byt v jednom souboru nebo v jinem – nemelo by to mit vliv na vysledek)
problem je v tom, ze klic pro cache bude uplne stejnej, takze se ulozi, ze bylo pouzito jak name, tak description a kazdy z obou dotazu vytahne i tyto dva sloupecky, presto, ze se oba nepouzivaji.
nemelo by v klici pro cache byt vic informaci? napriklad http request (url) nebo backtrace odkud bylo vytvoreno Nette\Database\Table\Selection? takhle je accessed cache celkem zbytecne. staci jedna stranka, kde treba vypisete vsechny clanky, vcetne textu atd. a to se pote bude tahat i pri vypisu jen treba nadpisu vsech clanku…
- hrach
- Člen | 1838
Ano, tebou popisovane chovani takove opravdu je.
- navrhovane upravy jsou spatne. ve vysledku by se nepodarilo vubec zaridit dobrou funkcnost. Url muzou byt velice ruznorode a protim by to neovlivnilo dotaz, ale mnostvi cachovanych souboru by byl neumerny.
- s backtrace je to podobne
- porad je efektivnejsi prunik sloupci nez
*
- ruku na srdce, tak moc casto stejne podminky nemas, to je jen testovaci priklad, vetsinou vybiras minimalne dle nejakych sloupcu.
- imo jedina mozna cesta, kam by se mohli ubirat upravy je moznost nastavit dane cachi sekci, napr. pro administraci, nebo jiny modul.
- David Matějka
- Moderator | 6445
jo, url byl opravdu spatnej napad. ale proc nepouzit backtrace? (nebrat v potaz argumenty, ale jen nazvy souboru, radky atd. odkud byla vytvarena instance selection)