Ref vybírá chybnou tabulku

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

Jde zřejmě o tentýž problém jako zde, jen pro metodu ref.

Mám tabulky (zjednodušeně):

client
- status_id - FK na status klienta
- id, jméno, příjmení etc.

client_status
- id, name (název stavu)

application (žádost)
- client_id - FK na klienta
- client_status_id - FK na TEHDEJŠÍ status klienta (z doby podání žádosti - proto jej zde ukládám "duplicitně")
- datum, stav žádosti, etc.

Když pak volám $application->client->lastname tak mi to hodí chybu že $client_status->lastname neexistuje – z toho vyvozuji, že místo tabulky client mě to odkázalo na tabulku client_status. Problém bude zřejmě zde.

Editoval jtousek (5. 10. 2012 11:41)

hrach
Člen | 1834
+
0
-

Nechces to opravit, ze bych pak udelal review? :)

jtousek
Člen | 951
+
0
-

Mohl bych, jen si nějak nejsem jistý, jak přesně by to mělo ve výsledku fungovat. Řekl bys mi jak to teď funguje u related ať to nemusím luštit? Asi by to mělo být podobné.

hrach
Člen | 1834
+
0
-

No ja si to vzdycky musim napsat na papir a vzdy mi chvilku trva, abych to pochopil. Takze ve chvili, kdy ti to ted zacnu vysvetlovat to uz musim chapat → to uz to muzu udelat rovnou :D

jtousek
Člen | 951
+
0
-

Aha, chápu. :-) Napíšu test, který bude failovat a uvidím. Když se mi podaří v rozumném čase pochopit jak to má být správně tak to i fixnu.

jtousek
Člen | 951
+
0
-

Ahááá už vím, čím to bylo. :-D Ono to totiž ten FK client_id nemělo v cache zatímco ten client_status_id ano. A protože client_status_id měl ten správný prefix („client“) tak se nezavolala metoda reloadForeignKeys – ta si nalezené klíče seřadí pomocí uksort takže by to nejdříve našlo sloupec client_id a k chybě by nedošlo. Posuď sám, jestli to je bug nebo ne. ;-) Kdybych tehdy smazal cache, což mne nenapadlo, chyba by pravděpodobně zmizela.

Editoval jtousek (5. 10. 2012 12:47)

hrach
Člen | 1834
+
0
-

Hm, tak to bug nebude. ;)