nette.database.default vs rucne vytvorenie (vs Reflection a cache)

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
matopeto
Člen | 395
+
0
-

Zdravim

prerabam jeden starsi projekt do DI a mam problem s databazou. (Pouzivam najnovsie nette 2.0.10)

V starom projekte sa databaza vytvarala natvrdo v BaseModel asi takto

	$dsn = "mysql:host={$options['host']};dbname={$options['dbname']}";
	$connection2 = new Nette\Database\Connection($dsn, $options['user'], $options['password']);

Databaza obsahuje spojovaciu tabulku medzi inou tabulkou a view. Kedze do view nejde vytvorit foreign key tak nebol vytvoreny. Aplikacia ale pracovala spravne.

Po prerobeni pouzivam nette.database.default, ktora sa autowiruje do BaseModel.

Bohuzial mam problem.

Prvy krat, ked este nie je vytvorena db cache aplikacia ide v poriadku.

Po nacachovani vsak vyhadzuje chybu typu:

"Row does not contain primary id column data"

Napadol ma problem s reflection, skusal som obe i Discovered `i `Conventional
Pokazde sa to nevie zmierit nad tou spojovacou tabulkou.

nechal som si vydumpovat povodny $connection a vidim, ze databaseReflection je NULL

Pokusil som sa teda nastavit reflection na NULL i v database.default bohuzial marne, vyhadzuje to, ze:

"Argument 1 passed to Nette\Database\Connection::setDatabaseReflection() must implement interface Nette\Database\IReflection, null give"

Co sice chapem, ale ako nastavit reflection na null? Pripadne v com by mohol byt problem?

Este male pozorovanie:

  • povodne connection nemalo cache ani reflection a stranku vygenerovalo za cca 400 ms
  • database.default s vypnutou cache a Conventional reflection funguje ale trva mu to cez 3s
enumag
Člen | 2118
+
0
-

„Row does not contain primary id column data“

Tahle chyba obvykle znamená že v nějaké tabulce nemáš definovaný primární klíč.

matopeto
Člen | 395
+
0
-

Ano to nemam. Do struktury databaze ale zatial zasahovat nechcem.

Skorej mi ide o to, preco to funguje, ked je connection definovane v kode, preco to funguje bez cache a preco to nefunguje inac.

enumag
Člen | 2118
+
0
-

Protože když Connection vyrábíš přímo (tebou popsaným způsobem) tak se cache nepoužívá, totéž když ji vypneš. Když se ale cache používá, je nutné mít nějaký cache-key a je naprosto přirozené, že NDB pro tento účel používá primární klíč, protože tabulky bez primárního klíče jsou zlo a měly by se zakázat.

matopeto
Člen | 395
+
0
-

Ano tiez chapem, ze ked to vytvaram rucne, tak cache nepouzivam, ale

  • povodne connection nemalo cache ani reflection a stranku vygenerovalo za cca 400 ms
  • database.default s vypnutou cache a Conventional reflection funguje ale trva mu to cez 3s

Takze problem bude asi niekde v Reflection, ktora je pri rucnom vytvoreni NULL ale do automatickej sluzby to null tam neviem dostat. Otazka je co to potom robi, ked je to null?

EDIT: tak nastavil som primary keys na vsetkych tabulkach a nejako to nefunguje. Asi je problem, ze je to viaczlozkovy kluc. A zasa pridavat umely nejaky autoincrement primary kluc mi pride zbytocne

EDIT2: a bohuzial jeden join robim s view a tam kluc nastavit nejde.

Editoval matopeto (17. 4. 2013 21:18)

matopeto
Člen | 395
+
0
-

Tak po par refreshoch (asi 5) stranky som sa dostal i s NDB (bez cachestorage) na 400ms na generovanie stranky. Tak to vyzera, ze konecne som sa dostal na ekvivalentnu definiciu.

enumag
Člen | 2118
+
0
-

@matopeto: Trochu jsem tě mystifikoval…

Tvé ručně vytvořené Connection používá defaultně ConventionalReflection – ta cache nepoužívá / nepotřebuje.

Connection vytvořené přes config.neon ve výchozím stavu používá DiscoveredReflection – ta pokud nedostane cache storage tak si ho stejně vytvoří a používá. V tomto případě prvních několik dotazů trvá déle než se cache vytvoří, pak už je to rychlé.

Když v configu refinuješ že chceš ConventionalReflection tak by to mělo být rychlé už od začátku. Na druhou stranu DiscoveredReflection mám raději.

Editoval enumag (18. 4. 2013 15:25)