Problém s where() při hledání přes více tabulek

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

Mám následující schéma:
Obrázek

Testovací obsah databáze zde:
http://leteckaposta.cz/392352891

Foreach, který má projít všechny záznamy v tabulce vozy_dopravci, které mají přes tabulku vuz v tabulce vozy_dopravci_poradivypisu navázan záznam s ID 1:

foreach($db->table('vozy_dopravci')
	->where('vuz_id.vozy_dopravci_poradivypisu:id', 1) as $f)
{
	dump($f->id);
}

Skončí chybou „No reference found for $vuz_id->related(vozy_dopravci_poradivypisu).“.

Bude to zřejmě tím, že DiscoveredReflection volá getHasManyReference a považuje vuz_id přímo za název tabulky, jímž není – je jen klíčem z první tabulky, který míří na druhou tabulku.

Dělám něco špatně, nebo je to nějaký bug?

hrach
Člen | 1838
+
0
-

Known bug / feature. Jde o to, ze v techto podminkach se v pripade DiscoveredReflection neuvadi tabulky, ale vazebni vyrazy, ze kterych se sestavuje vysledny dotaz. Takze treba
->where('moderator.name', 'Jan Skrasek') zpusobi v DiscoveredReflection match na sloupce moderator_id a pres reflexi se precte, ktera tabulka na tento sloupec odkazuje.

Problem je ten, ze bohuzel pokud tento automaticky match selze (napr. ze vice tabulke v tomto pripade odkazuje na stejny sloupec, ci diky spatnym jmennym konvencim – tvuj pripad), tak neni mozno NDB napovedet, co tam dodat za data. Toto je mozno zatim jen v primych metodach ref, related.

Pokusim se uspisit opravu tohoto chovani.

Eda
Backer | 220
+
0
-

Ok, díky za info.

Je to ale trošku paradoxní. Protože skript ví, kam vede to první propojení – v mém případě do tabulky vozy. Když se ale snaží sestavovat další propojení (z vozy do vozy_dopravci_poradivypisu), snaží se použít ten vazební výraz (vuz_id) místo toho, aby použil přímo název tabulky, který již zná (protože ji už úspěšně napojil…). Takže by stačilo teoreticky jen používat již nalezený název propojené tabulky místo klíče a bylo by vystaráno. Ale chápu, že to nemusí být implementačně tak jednoduché…

Tak hodně štěstí s opravou, budu se těšit.

hrach
Člen | 1838
+
0
-

Ha, spatne jsem si precetl. Mnou popsany pripad existuje tez, ale to, co si napsal ty je uknown bug.
Mohl bys pls testnout toto? https://github.com/…h-joinparser Jde jen o jednoradkovou zmenu.

Eda
Backer | 220
+
0
-

Díky za opravu, stále to ale nefunguje. Stejný kód s tebou odkazovanou verzí nyní hází chybu:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'vozy.id' in 'on clause'

Kód vygeneruje SQL dotaz:

SELECT `vozy_dopravci`.*
FROM `vozy_dopravci`
INNER JOIN `vozy` AS `vuz_id` ON `vozy_dopravci`.`vuz_id` = `vuz_id`.`id`
INNER JOIN `vozy_dopravci_poradivypisu` ON `vozy`.`id` = `vozy_dopravci_poradivypisu`.`vuz_id`
WHERE (`vozy_dopravci_poradivypisu`.`id` = ?)

Problém je evidentně v tom, že u dalších JOINů v navázáních nepoužíváš alias (zde by mělo být vuz_id.id), ale původní název tabulky (zde vozy.id).

hrach
Člen | 1838
+
0
-

repush, zkus ;)

Eda
Backer | 220
+
0
-

Paráda, díky! Až přijdu domů, otestuju, ale vypadá to funkčně :-)

Btw: Ty chodíš taky na FI MU, že?

hrach
Člen | 1838
+
0
-

No chodim no, tento tyden me zacatek skoly prekvapil, pocital sem s tim az za tyden :D