cache výsledků dotazů z databáze, cacheování primárních klíčů
- Reloecc
- Člen | 15
nette v2.0.10
Ahoj, dobrý den..
i stalo se, že jsem vytvořil kód, v němž funguje stránkování záznamů
z MySQL, volané ajaxem, jež invaliduje snippet, který se správně zobrazí,
neviděl bych v něm problém.
Problém nastal ve chvíli, kdy jsem v databázi provedl změnu, jež změnila pořadí prvku (přesněji do stránkování předsadila jeden záznam na první straně stránkování).
A co se stalo: php na druhé straně stránkování začalo hlásit ‚undefined offset‘ v poli (ze záznamu databáze).
Konkrétněji: před editací databáze se zobrazovaly záznamy
(řekněme)
na první straně [1, 2, 3], na druhé straně pak [4, 5, 6].
Po přidání záznamu se měly (dle nastavených podmínek orderu a selectu)
zobrazit záznamy
na první straně [7, 1, 2], na druhé [3, 4, 5], na třetí [6].
- Avšak, dle mého soudu, díky cache nette, který uložil někde něco, zahlásilo php při výpisu druhé strany ‚undefined offset 3‘. Z mého pohledu proto, že
- dotaz pro výpis 2. strany byl v obou případech stejný: ‚SELECT * FROM [table] LIMIT 3 OFFSET 3‘
- primární klíče výsledku dotazů nebyly kešlé, tedy [3, 4, 5]
- ale výsledek dotazů (data) kešlý byl, tedy [4, 5, 6]
po smazání cache chyba zmizela..
a já se ptám, je toto možné, že by se zakešovalo vše, krom primárních klíčů výsledku dotazu?
nechci uvádět vlastní kód, myslím, že otázka je čistě teoretická.. díky za zvážení a odpověď
- Petr Hudík
- Člen | 49
Čistě v rámci teoretické roviny, popsané chování nedokážu vysvětlit, Nette samo o sobě nic takového necachuje. Bohužel neuvádíš zda používáš Nette\Database nebo něco jiného. Vlastně moc nerozumím této části:
Reloecc napsal(a):
A co se stalo: php na druhé straně stránkování začalo hlásit ‚undefined offset‘ v poli (ze záznamu databáze).
Proč to načítáš do pole? jakým způsobem to tam dostáváš a jakým způsobem to vytahuješ?
Rozumím, že nechceš uvádět vlastní kód, ale už samotné vypsání záznamů mi přijde zvláštní a tak se bez trochu konkrétnějšího příkladu asi obtížně obejdeme.
Editoval Petr Hudík (14. 5. 2013 9:52)
- hrach
- Člen | 1838
Vypada to presne na tento bug, ackoliv po refreshi by to melo byt ok, pac ten bug se tyka jenom teoretickeho refetechte radku v jednom pageview.
- Reloecc
- Člen | 15
jasně, moje chyba, jedná se o Nette\Database, a uvést kód mi neděla problém, jen mi přišel zbytečný, pro můj dotaz
data tedy získávám z
/** @var $connection \Nette\Database\Connection*/
$data = $connection->table('table_name')->where('display', 1)->order('date_end DESC')->limit(3, 3);ta předám šabloně,
$data_new = array();
foreach($data as $row){
/** operace nad výsledkem z db */
$data_new[] = $row->toArray();
}
$template->data = $data_new;kde je pak vypisuji do snippetu pomocí
{snippet data}
{foreach $data as $item}
{$item['key']}
{/foreach}
{/snippet}tedy nic magického…
data se do šablony dostávají jako pole, neboť jejich příprava pro render toto vyžaduje.. vypsat celý chod konkrétně a ze všech částí kódu je nemyslitelné.
Jestliže v tomto zkráceném zápisu není evidentní paskvil, který by mohl způsobit chybu, budu to považovat za výjimku, způsobenou slunečními erupcemi.
Pro upřesnění: situace nastala, když volání selectu z db proběhlo „zároveň“ společně se zobrazováním daného dotazu (ajaxem, výpisem ve snippetu), nevím, jestli to může být příčinou. Chyba zůstala pak persistentní, až do smazání nette cache. Nedaří se mi chybu reprodukovat, proto příčině nebudu věnovat pozornost, snad se znovu neobjeví..
I tak však děkuji za odpověď.
Editoval Reloecc (14. 5. 2013 11:40)