Nette 2.4 – změna v cachování NDB?

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
před 8 lety
kolsi
Člen | 131
+
0
-

Chtěl bych se jenom zeptat, změnilo se v Nette 2.4 něco ohledně cachování oproti předchozímu Nette 2.3 ?

Mám ten problém, že po přechodu na 2.4 se to chová naprosto nepředvídatelně. Např. tento jednoduchý kód:

$project = $this->projectRepository->findById($id);
Debugger::barDump($project->label);

Po upgradu na Nette 2.4 to hlásí, že nezná sloupec „label“. Když vypíšu proměnnou $column (tj. ActiveRow), tak z celkovým 10 sloupců obsahuje jenom 3. Smažu cache a funguje to. Pak ale na jiné stránce přistupuju k jinému sloupci a začne to zase hlásit, že nezná ten jiný sloupec. Smažu cache a funguje, ale zase přestane fungovat to původní.

před 8 lety
Gappa
Nette Blogger | 208
+
0
-

To mi připomíná tohle:

Na jednom projektu se mi to chová podobně – nějakou dobu to vždy funguje, pak se to „samo rozbije“, smažu cache, nechám přegenerovat a zase to funguje.

Co s tím, tak to bohužel zatím nevím.

před 8 lety
kolsi
Člen | 131
+
+1
-

Tam koukám, že tazatel má Nette 2.2. Mně to začlo dělat až s přechodem na Nette 2.4 a dělá to poměrně často.

Nějak víc jsem to zatím nedebuggoval, ale přijde mi, že když načtu nějakou stránku, která přistupuje k některým sloupcům v tabulce, tak se tyto sloupce nacachují. Pak když otevřu jinou stránku, která přistupuje k jiným sloupcům, tak už to kouká jenom do cache a zahlásí chybu, že ten sloupec nezná.

před 8 lety
Pavel Kravčík
Člen | 1196
+
0
-

Tohle nepomůže? https://github.com/…ase/pull/137

Jinak stávalo se mi to taky, když jsem pro podobný dotaz vybíral explicitně sloupce a jiné pak nechtěl, už si to přesně nepamatuji, ale na jednom projektu pomohl tento fix a na další úprava SQL v ORM.

před 8 lety
kolsi
Člen | 131
+
0
-

Ten fix je starý už skoro, takže předpokládám, že v aktuální verzi Nette je zahrnut a tudíž vliv na problém nemá.

před 8 lety
kolsi
Člen | 131
+
0
-

Tak po několika dnech používání Nette 2.4 musím konstatovat, že je absolutně nepoužitelné. Kolikrát nefunguje ani nastavování dat do formuláře, protože ActiveRow prostě neobsahuje všechny sloupce z DB dokud nesmažu cache. A mazat cache 20× denně trochu nedává smysl.

před 8 lety
Pavel Kravčík
Člen | 1196
+
0
-

kolsi napsal(a):

Tak po několika dnech používání Nette 2.4 musím konstatovat, že je absolutně nepoužitelné.

U nás naopak, všechny projekty, které jsme migrovaly na 2.4 fungují jako po másle. :)

Zkus ještě mrknout do composeru, jestli požaduješ nejnovější cache realese (2.5), třeba pomůže. https://github.com/…ing/releases

před 8 lety
Jan Tvrdík
Nette guru | 2595
+
+1
-

@kolsi Dokážeš ten problém reprodukovat a izolovat?

před 8 lety
kolsi
Člen | 131
+
0
-

Reprodukovat jo, ale absolutně to nechápu. Nejjednodušší případ, kdy se mi to podařilo vyprodukovat je následující. Udělal jsem úplně prázdný presenter (zděděný od Nette\Application\UI\Presenter) s metodou actionDefault.

/** @var ProjectRepository @inject */
public $projectRepository;

public function actionDefault() {
		$project = $this->projectRepository->findById(1);	// volá get() nad příslušnou tabulkou
		echo $project->label;
}

Smažu složku temp\cache a načtu stránku, vše je ok. Vypíše se správný výsledek. Následně doplním testovací výpis:

public function actionDefault() {
		$project = $this->projectRepository->findById(1);
		echo $project->label;
		Tracy\Debugger::barDump($project);
}

Refreshnu stránku a dostanu jenom error „Cannot read an undeclared column ‚label‘“.
Odebrání přidaného barDump nepomůže. Pokud znovu smažu temp\cache a refreshnu stránku, tak to už funguje.

Pokud po chybě dám ten barDump před „echo…“, tak v dumpu vidím jenom sloupce id+name (label tam není).

před 8 lety
kolsi
Člen | 131
+
0
-

Bude se tímto problémem někdo zabývat, nebo je třeba ho nahlásit do nějakého oficiálního trackeru? Smažu cache, otevřu jinou stránku a slítne to jinde a můžu jí mazat znovu.

před 8 lety
Pavel Kravčík
Člen | 1196
+
0
-

Hoď někam github sandbox s replikací. Pak se na to může někdo podívat. Největší šance na chybu je v tvém repositáři hádám.

před 8 lety
kolsi
Člen | 131
+
0
-

Tak chyba může být samozřejmě kdekoli, to nevylučuju. Jediné, co mohu na 100% potvrdit je, že v Nette 2.3 se to nestalo ani jednou a po upgradu na Nette 2.4 ten úplně stejný kód hází náhodně tuto chybu tak 20× denně.

Pokud se problém snažím vyvolat uměle, tak většinou neuspěju, ale jakmile pracuju, tak to dělá každou chvíli.
Náš konkrétní kód bohužel zveřejnit nemohu.

před 8 lety
filsedla
Člen | 101
+
0
-

Jak vypadá findById()? Nepoužíváš tam nějakou magii (__call)?

před 8 lety
kolsi
Člen | 131
+
+1
-

findById() nedělá nic speciálního než $this->getTable()->get($id) a getTable() jenom $this->connection->table(‚tabulka‘);

Zatím to vypadá, že k vyvolání problému vede konkrétní kombinace akcí (resp. po sobě jdoucích dotazů do stejné tabulky). V debuggování budu pokračovat v pondělí, tak kdyby byl nějaký nápad, co mám sledovat, tak zkusím.

před 8 lety
kolsi
Člen | 131
+
0
-

Může samovolně docházet k vymazání cache i v průběhu?

Normální situace – pokud smažu cache ručně, tak při prvním obnovení stránky se provádí dotazy jako „SHOW FULL TABLES“, „SHOW FULL COLUMNS“ atd. Při dalším načtení stránky se už tyto dotazy neprovádí.

V době, kdy ale nastane zmiňovaná chyba, je v Tracy zalogováno pár normálních dotazů, a pak se najednou volá „SHOW FULL TABLES“ atd. jako při obnově cache. Následně to spadne v ActiveRow.php, ř. 299, že neexistuje sloupec. A vypadá to, že v ActiveRow::$data jsou v tu chvíli uloženy pouze sloupce, které byly načteny před tím samovolným refreschnutím cache.

V tuto chvíli se problém vyskytuje na řádku return $position->edit_allowed;, kde ho dokážu vyvolat pokaždé. Je zvláštní, že SQL dotaz volaný z toho řádku je pouze:

SELECT `id` FROM `organization_position` WHERE (`organization_position`.`id` = 23)

Jeho výsledek tak obsahuje pouze sloupec „id“, ale už nikoli edit_allowed. To vyvolá refreshnutí cache a následnou výjimku „column not found“

Editoval kolsi (3. 4. 2017 12:12)