API pro Nette\Database\Table\Selection

David Grudl

Hlavní věc, kterou jsem chtěl na NotORM při začlenění do Nette změnit, bylo API. Původní API mi absolutně nevyhovovalo, protože nebylo čitelné. Bez pohledu do dokumentace člověk netušil, která bije.

Současná podoba ale stále není ideální:

nejvíc mi vadí trojice metod find() vs where() vs get() vs fetch() u kterých není zcela zřejmé, jak se liší (zásadně)
nejsem si jist, jestli ArrayAccess u Nette\Database\Table\Selection (nikoliv nad řádkem) má své opodstatnění
s odstupem času si nejsem jist, jestli by $connection->table('...') nemělo být přece jenom $connection->getTable('...')
vadí mi ->order('column DESC'): jednak order bych změnil na orderBy nebo sortBy() a pro DESC vytvořil vlastní metodu nebo použil něco lepšího než DESC v řetězci.

Lets brainstorm!

uestla

Let's do it then!

$connection->getTable('tableName')->getByPrimary($key);
$selection->orderBy('columnName')->orderDesc(TRUE);

Možná abych šel raději spát…

bojovyletoun

podle mě označení Fetch je standartní všude
find se mi líbí, dělá přesně to, jak se jmenuje, najde (vyfiltruje podmínkou where) konkrétní záznam
[] se asi v praxi nevyužívá
getTable je logičtější

hrach

nesouhlasím s getTable. Jedna věc je logičtější api než ->users(), nicméně mi to přijde zbytečně dotažené do absurditiy.
Stejně tak se moc netvářím na orderBy, ikdyž to si umím předstvit. U toho tablu je problém, že to používá vždy…

#mluvím jako uživatel Nette Database.

petr.pavel

Osobně se stavím proti myšlence klonovat NotORM a upravovat ho. Přijde mi lepší mít NotORM přímo od Jakuba rovnou v distribuci Nette s nějakým wrapperem.

Můj pohled na věc je, že je lepší se specializovat, než se snažit obsáhnout vše. Takové Multics vs. Unix.

Honza Marek

David Grudl napsal(a):

nejsem si jist, jestli ArrayAccess u Nette\Database\Table\Selection (nikoliv nad řádkem) má své opodstatnění

Určitě ne, nezdá se mi to čitelné.

s odstupem času si nejsem jist, jestli by $connection->table('...') nemělo být přece jenom $connection->getTable('...')

Víc se mi líbí table, protože API Nette\Database je takové DSL, tak ať se to příjemněji používá.

westrem

Nepracujem s Nette Database takze sa vyjadrim len z pohladu neznaleho pozorovatela:

get() vs find() vs fetch() – bez toho, aby som sa adhoc pozrel do dokumentacie nedokazem z nazvu tychto metod odvodit v com sa lisia a to je podla mna problem. Fetch mi evokuje ziskanie jedneho zaznamu z uz vykonanej query (ktora ma vo vysledku viacero zaznamov). Get mi pride ako obecna metoda na ziskanie nejakeho resultu nezavisle na tom ci sa jedna o jeden riadok alebo o viacero zaznamov. Find je podla mna synonymum k najdeniu jedneho alebo viacerych zaznamov podla nejakeho kriteria – ergo. argumentu. Neviem ci vam to bude prospesne, ale toto je moj pohlad na vec.
order() vs orderBy() – osobne sa priklanam k verzii orderBy() pretoze je analogicka SQL variante, kde sa pise ORDER BY a nielen samotne ORDER – minimalizuje to tak mozne nezrovnalosti pre zaciatocnikov. K DESC – mozno odveci napad ale co takto: orderAscendingBy() a orderDescendingBy()?

David Grudl

Ony samotné metody find(), get() a where() jsou poměrně výstižné. Problém je, že jak existují pospolu, už není na první pohled zřejmé, jak se liší:

Dovedete bez pohledu do zdrojového kódu říct takhle z hlavy říct, co je chybně a jak se příklady liší?

...->find($id)

...->find('email', $email)

...->where('email', $email)

...->find($id)->get()

...->find($id)->fetch()

...->get($id)

Možná pojmenování find a where sjednotit na nějake find & findKey nebo where & whereKey. Obdobně potom fetch a get na fetch & fetchKey (ačkoliv tohle není moc šťastné).

David Grudl

westrem napsal(a):

get() vs find() vs fetch() – bez toho, aby som sa adhoc pozrel do dokumentacie nedokazem z nazvu tychto metod odvodit v com sa lisia

To je přesně ono. V tuto chvíli je pro diskusi cennější neznalost ;-)

juzna.cz

Ja Nette\Database neznam, ale pri prvnim pohledu me napadne:

...->find($id) // vrati objekt podle primarniho klice
...->find('email', $email) // vrati objekt podle sloupce
...->where('email', $email) // vrati neco jako Select, co muzu dal retezit napr s orderBy
...->find($id)->get() // type error
...->find($id)->fetch() // type error
...->get($id) // netusim

(mam zkusenosti s dibi, Doctrine a Zend Db)

David Grudl

Hádal bych podobně. A přitom ses trefil jen u toho where().

Yrwein

Celkem hezky pojmenované metody má Propel: findPk[s], findOne[BySomething], find[BySomething] — plus bych se nebál oddělit získání výsledku od práce s ním. Tzn. find by vracelo nějakou Collection a ta by na sobě měla metody ala fetch[Pairs], implementaci ArrayAccess apod. (Nebo má nějaký důvod, že je to takto pohromadě?)

Patrik Votoček

hádám:

...->find($id) // netusim
...->find('email', $email) // netusim
...->where('email', $email) // vrati neco jako Select, co muzu dal retezit napr s orderBy
...->find($id)->get() // to same co ->get($id)
...->find($id)->fetch() // pole obektu podle ID (nevim proc)
...->get($id) // vrati objekt podle primarniho klice

kdybych nevěděl o existenci get() hadal bych jeji funkčnost u find().

Z luhů a hájů doctrine 2:

...->find($id) // vrátí objekt podle primarního kliče
...->findBy(array('foo' => "Bar")) // vrati pole obektu jejichž property `foo` je rovná `Bar`
...->findByFoo("Bar") // stejné jako předchozí
...->findBy(array('foo' => 1, 'bar' => "Test")); // vice podminek
...->findByFooAndBar(1, "Test"); // stejné jako předchozí
...->findOneBy(array('foo' => "Bar")) // vrati objekt jejihož property `foo` je rovná `Bar`
...->findOneByFoo("Bar") // stejné jako předchozí
...->findOneBy(array('foo' => 1, 'bar' => "Test")); // vice podminek
...->findOneByFooAndBar(1, "Test"); // stejné jako předchozí
...->findAdd() // vrátí všechny objekty bez podmínek
...->createQueryBulder('foo')
	->where('foo.bar = :bar')
	->setParameter('bar', "Test")
	->getQuery()->getResult(); // getSingleResult() / getScalarResult() / getSingleScalarResult()

pokud findOneBy[xxx] najde více jak jeden řádek vyhodí vyjímku.

bojovyletoun

Já jsem proti míchání názvů slupců do názvů metod: je to magické, IDE nenapovídající a špatně se to parametrizuje

rixi

Som za zachovanie sucasnej podoby notorm-like. Camel pomenovania mi na tak jednoduche prikazy ako table, select, from, order pripadaju zbytocne.

A metodu pre vyber skor find() ako get(). Takto ma lahsie napadne, ze metoda moze sluzit len na vyber, ako aj na viac (dosadit metody update, delete, atd). Neviem ci je to vhodne, resp. ake nasledky prehliadam, ale pacilo by spravanie takto:

$database->find(1); // WHERE id = 1
$database->find('published', 1) // WHERE published = 1
$database->find(array('published' => 1)); // WHERE published = 1