Nette\Database ORM Challenge

Tak přikládám slibovanou implementaci v YetORM: https://bitbucket.org/…rm-test/src/.

U YetORM jsem byl trochu zklamaný z toho, že všechny instance entit jsem si nakonec stejně musel vytvářet sám. Doufal jsem, že to bude YetORM dělat tak nějak automaticky. Na druhou stranu je tam docela hezká berlička pro M:N vazby, které jsou v čisté NDB jak známo trochu problém.

Mimochodem, spustil jsem si Tvé řešení v YetORM a mám k tomu dvě věci:

1) Jsi si jist, že dodržuješ své vlastní zadání ;)? Mám podezření, že ty články nemáš seřazené od nejnovějších (tj. sestupně podle id).

2) Lean Mapper položí následující čtyři dotazy:

SELECT `article`.*
FROM `article`
ORDER BY `id` DESC

SELECT `article_category`.*
FROM `article_category`
WHERE `article_category`.`id` IN (1, 3, 2)

SELECT `article_2_tag`.*
FROM `article_2_tag`
WHERE `article_2_tag`.`article_id` IN (31, 30, 29, 28, 27, 26, 25, 24, 23)

SELECT `tag`.*
FROM `tag`
WHERE `tag`.`id` IN (2, 3, 4, 1, 5) AND `deleted` != 1

Zatímco YetORM (Nette\Database?) jich položí celkem osm a jsou trochu divné:

SELECT `id`, `title`, `article_category_id`, `content_html`
FROM `article`

SELECT `id`, `name`
FROM `article_category`
WHERE (`id` IN (1, 2, 3))

SELECT `article_2_tag`.`id`, `article_2_tag`.`article_id`, `article_2_tag`.`tag_id`
FROM `article_2_tag`
LEFT JOIN `tag` ON `article_2_tag`.`tag_id` = `tag`.`id`
WHERE (`article_2_tag`.`article_id` IN (23, 24, 25, 26, 27, 28, 29, 30, 31)) AND (`tag`.`deleted` =
0)

SELECT COUNT(*), `article_2_tag`.`article_id`
FROM `article_2_tag`
LEFT JOIN `tag` ON `article_2_tag`.`tag_id` = `tag`.`id`
WHERE (`article_2_tag`.`article_id` IN (23, 24, 25, 26, 27, 28, 29, 30, 31)) AND (`tag`.`deleted` =
0)
GROUP BY `article_2_tag`.`article_id`

SELECT `id`, `name`
FROM `tag`
WHERE (`id` IN (1, 2, 5))

SELECT `id`, `name`
FROM `article_category`
WHERE (`id` IN (1, 2, 3))

SELECT `id`, `name`
FROM `article_category`
WHERE (`id` IN (1, 2, 3))


SELECT `id`, `name`
FROM `article_category`
WHERE (`id` IN (1, 2, 3))

Proč tolik dotazů? A proč se druhý dotaz v pořadí pak ještě třikrát opakuje?

Neměly být podobné věci ve stable Nette 2.1 již vyřešené? Anebo je to problém YetORM?

Implementace ve Fabik/Database: https://bitbucket.org/…ase-test/src.

Fabik/Database se mi ve výsledku líbí. Automatické mapování výsledků na entity funguje perfektně, dokonce i při takovýchto voláních. Na druhou stranu nevím, co vlastně mají představovat potomci Fabik\Database\Table a jak bych měl s nima pracovat (IMHO to budou vždy prázdné třídy, dědící z Fabik\Database\Table). Taky bohužel Fabik/Database není updatovaný na aktuální Nette, a tak jsem mu musel šáhnout do zdrojáků a zakomentovat tam 4 řádky.

EDIT: Zapomněl jsem na řazení :-D řazení přidáno

Editoval nanuqcz (2. 2. 2014 23:54)

Tak, řazení v obou projektech opraveno :-)

@uestla obrácená podmínka?!? Co to je? :D

Možná to ve výsledku dělá to, co by to dělat mělo, ale ta konstrukce je pro mě nečitelná a už vůbec ne intuitivní. Neexistuje jiné řešení?

@uestla: Díky za vysvětlení. Jsem upřímně rád, že to nebyl bug v Nette\Database.

@Majkl578: Hezký!

EIFEL napsal(a):

Huh ta Doctrine me prijde teda dost ukecana

No tak samozřejmě můžeš použít jen findAll()/findBy(), ale to pak nebudou ty dotazy přes vazby optimalizované. Ten filtr na tagy bych osobně udělal globálně, ale nechtěl jsem příklad komplikovat. Další „úspora“ v ukecanosti je nepoužívat query builder, ale ten je mi pohodlnější.

Souhlasím, taky mi to přijde spíš jako výhoda než nevýhoda. Nemám rád zkratky, zkrácené zápisy a moc „generované magie“. :) Ty anotace by se daly asi taky zjednodušit, akorát protože používáš nestandardní názvy sloupců, není pro to moc prostor. Případně je můžeš mít někde bokem v neonu/yamlu.
Plus ještě ukecanost v getterech/setterech, ale ta je spekulativní, např. v Kdyby/Doctrine je BaseEntity, která tohle automatizuje (ač na můj vkus je to už moc magické) a celá entita pak může vypadat např. takto stručně (samozřejmě vlastnosti protected, nikoliv public).

Standardní ve smyslu defaultní je název entity/vlastnosti/asociace == název tabulky/sloupce (např. „contentHtml“ == „contentHtml“). To je defaultní naming strategie. Pak ještě disponuje underscore steategií kdy „contentHtml“ == „content_html“. Případně si můžeš implementovat vlastní (viz odkaz).

nanuqcz napsal(a):

Majkl: Mě ta Dotrine přijde takhle na první pohled super. Ukecanost vidím jen trochu v anotacích entit (možná tohle myslel EIFEL).

Jj šlo mě spíš o anotační ukecanost. Každopádně se na Doctrine jednou chystám, ale zatím si vystačím s LeanMapperem a není čas laborovat s Doctrine

Editoval EIFEL (3. 2. 2014 16:33)