NDB join více tabulek a operace nad selection

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

Zdravím,

mám např. jednoduché schéma DB:

CREATE TABLE domain (
id int(11) NOT NULL AUTO_INCREMENT,
name varchar(25) NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE product (
id int(11) NOT NULL AUTO_INCREMENT COMMENT ‚Id‘,
name varchar(20) NOT NULL COMMENT ‚Admin name‘,

domain_id int(11) NOT NULL DEFAULT ‚1‘,
PRIMARY KEY (id),
KEY domain_id (domain_id),
CONSTRAINT product_ibfk_1 FOREIGN KEY (domain_id) REFERENCES domain (id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Pokud chci obě tabulky vypsat v NDB, tak pochopitelně použiji konstrukci jako:

$conn->table('product')
	->select('product.*');
	->select('domain.name AS domain_name');

Což mi dá všechno do jedné struktury a já to mohu krásně vypsat.

Nicméně daná data bych chtěl z různých důvodů i updatovat a to ideálně skrze selection (mám komponentu, která vypisuje tabulku a umí několik jednoduchých handlů s danými daty).

Čili použiji např.:

$row = $selection->get(1);

Což vyhodí chybu:

SQLSTATE[23000]: Integrity constraint violation: 1052 Column ‚id‘ in where clause is ambiguous

Což se stane, protože je voláno wherePrimary, které dosadí primární klíč (popř. sekvenci). Nicméně je to uloženo např. jen jak id. Pokud chci aby, vše fungovalo, tak musím udělat:

$row = $selection
	->where($selection->name . '.id =?',1)
	->fetch();

Je toto správně? A pokud ano, nebylo by smysluplné doplnit $selection->name do metody getPrimary, aby to fungovalo více out of box? Nebo někde dělám chybu?

Caine
Člen | 216
+
0
-
hrach
Člen | 1836
+
0
-

Jako mas pravdu, je to chyba, ale ne tak zasadni, protoze to zrejme blbe pouzivas. Zkus prosim si projit mou prezentaci: http://public.skrasek.com/…_2012_04_28/

kedrigern
Člen | 102
+
0
-

@Caine: Dík.

@hrach: Možná je to neopodstatněná nedůvěra, ale pokud mám natural join, tak mi připadá rozumnější nechat ho udělat už samotnou DB (např. i kvůli abecednímu řazení z druhé tabulky) a nadále s tím pracovat, než to vyzobávat po řádcích. Přecijen je to třeba 1 vs 41 dotazů a natural join nebude trvat nějak dlouho (navíc se nacachuje).

Rozsekáno do tolika tabulek to mám kvůli konzistencí napříč DB, jelikož MySQL neumí globální enum – čili tam mám dost tabulek, které mají jen PK a nějaký string (víceméně).

Prezentaci jsem viděl. Je pravda, že jsem zmatený, jelikož dokumentace (alespoň v době, kdy jsem jí četl) je docela strohá a moc podobné případy nepopisuje.


Mimochodem je někde dokumentace změň v v 2.1? Koukal jsem, že @dev verze mi hází depracted etc. (To jen tak na okraj)

hrach
Člen | 1836
+
0
-

Tak jestki mas v tabulce 41 enumu tak ano, asi to bude horsi. Nadruhou stranu kvuli razeni to horsi nebude, protoze je rozdil delat join kvuli indexu a kvuli fetchovani dat. Index je rychly. Na dokumentaci moc nekoukej, doporucuji hlavne to video plus prezentaci, to musis pochopit, bez toho ti ndb bude jen klacek pod nohy.

kedrigern
Člen | 102
+
0
-

Jo chápu :), děkuji moc.