Podle čeho volí Database sloupce za SELECT
- bumprask
- Člen | 59
Zdravím,
mohl by někdo prosím ve stručnosti objasnit podle čeho Nette Database volí
sloupce, které se mají vybrat, tedy parametry za SELECT? Jde o to, že mám
jednoduchý dotaz
`$this->getContact()->where("identity_id",$id)->fetch()`
`SELECT identity_id, person_type_id FROM contact WHERE identity_id = ?`u kterého předpokládám, že vrátí všechny záznamy z tabulky CONTACT, ovšem výsledný SQL vybírá pouze dva sloupce a to identity_id a person_type_id (cizí klíč). Primárním klíčem je identity_id a je zároveň i cizím klíčem do tabulky IDENTITY. Nechápu proč zrovna tyto dva sloupce…co na to tedy může mít vliv?
Pozn.: nemluvě o produkčním serveru, kde se příkaz chová opět jinak, nevybere identity_id, zato to pošle plno dalších sloupců, ale né všechny, pouze jiné než na localhostu.
Napadlo mě, že bych mohl mít nějakého skřeta v reflection, ale to je pro mě magie…
Editoval bumprask (30. 10. 2012 11:53)
- bumprask
- Člen | 59
Trochu sem to prozkoušel, ale očividně vymazání catche mi to neovlivnilo. Po vymazání vygeneruje opět jenom dva sloupce. Na localhostu je jedním s vrácených alespoň identity_id (primární klíč), na hostingu ovšem nikoliv, tudíž to končí na hlášce..
Row does not contain primary id column data
Jedna věc je, že na serveru vrátí SELECT bez primárního klíče a druhá
věc je že hledá primární klíč pod konvenčním názvem. Podle hlášky se
snaží nalézt primární klíč s názvem „id“. Primární klíč
v mojí tabulce je ovšem pojmenován jako cizí klíč, jeliko je zároveň
cizím klíčem do tabulky identity, jelikož využívá architektury ISA a
dědičnosti entit.
Problém s výběrem primárního klíče je POUZE na serveru.
Editoval bumprask (30. 10. 2012 13:09)
- bumprask
- Člen | 59
Moc nechápu to, že na localhostu dojde k výběru primárního klíče a
na serveru ne. Pokud přidám
k výše zmíněnému dotazu pro výběr kontaktů ->select(„*“)
…dostanu co potřebuju, ovšem bez specifikovaného ->select() můžu jen
odhadovat co database provede…
EDIT: tak zkusil jsem zjistit jaký bere primary key pomocí getPrimary(), na localhostu je primary key „identity_id“ kdežto na serveru „id“ …zde bude zakopán pes, ovšem zatím opravdu nevím co s tím…
Editoval bumprask (30. 10. 2012 13:19)
- bumprask
- Člen | 59
Hmmm, tak tohle už zavání černou magií…podle všeho discoveredReflection je aktivní, jelikož sousední tabulka se stejnou strukturou vrací primary key „identity_id“, což značí to, že dicovered disoveruje, tedy i InnoDB je v cajku…tak jak je možné, že na jedné tabulce neproběhne nalezení primárního klíče a předhazuje to pořád jako primární klíč konvenční „id“, když u jiných to pracuje správně?
Editoval bumprask (30. 10. 2012 14:05)
- bumprask
- Člen | 59
Tak chyba objevena, po prozkoumání getPrimary() sem zjistil, že se používají pořád data s cache, u které jsem byl přesvědčen, že jsem jí mazal, ovšem díky zamítnutí přístupu na ftp se nemazala celá cache a zůstával tam právě ten záznam co v tom dělal neplechu…hrome, jak já miluju tyhle chyby…
Takže další problém, za kterým stála nesmazaná cache, ach jo. Každopádně děkuji za nasměrování, alespoň sem měl možnost poznat blíž vnitřnosti nette database :-)