Connection: alternative order of statement and arguments

[paranoiq]

v PDO / NotORM / Nette\Database\Connection je u metod query(), exec(), fetch...() pořadí takové: nejdřív statement, potom všechny argumenty. ve statementu se pozice argumentů označuje otazníkem

při složitějších dotazech s mnoha argumenty z toho vzniká naprosto nečitelný kód, kde se na konci kupí hromada proměnných a není na první pohled jasné, který argument kam patří

líbila se mi syntaxe dibi, kde byly útržky statementu prokládány argumenty samými. lze to velmi snadno docílit i v N\D\C. zatím používám takovéhle rozšíření: https://gist.github.com/1277781

detekce staré/nové syntaxe je podle toho, že v nové nejsou otazníky

[paranoiq]

teď jsem zjistil, že před PDO ještě argumenty zpracovává SqlPreprocesor a tohle by byla práce pro něj.

jenže v některých věcech opravdu není ideální: např. nelze mu předat pole argumentů pro WHERE a na INSERT ON DUPLICATE KEY UPDATE úplně selže, protože obě pole považuje za VALUES. dál třeba neošetřu typ (int) před LIMIT a OFFSET

pokud by ses k tomu Davide nějak vyjádřil, začal bych na tom dělat. stávající stav mi velmi nevyhovuje. nebo mám napsat RFC? :P

víc tady: http://forum.nette.org/cs/8866-novy-sqlpreprocessor-pro-nette-database

[dg]

Vypadá to zajímavě, nějaké návraty k Dibi rozhodně budou. Ale už bych to nezařazoval do verze 2.0, do nějaké další.

[paranoiq]

je to zpětně kompatibilní, takže by to doufám nic rozbít nemělo (to je třeba otestovat). ale předpokládam, že do verze 2.0 už to nestihnu ;-]

souviselo by to s refaktoringem Selection::where() - aby si nemusela skládat podmínky sama. zkusím vyrobit patch až bude čas

[dg]

Super.

[paranoiq]

první část tady: https://github.com/paranoiq/nette/commit/0dd2e7556473234d0a311575f999d90582387337

narazil jsem problém, který asi nelze vyřešit jinak než BC breakem - v původním PDO::query je volitelný druhý parametr volba FETCH_XYZ. v NDB je odsunuta parametry dotazu na poslední místo. s novou syntaxí ale počet parametrů není znám (nejsou placeholdery) a zpracovávají se všechny parametry. tudíž nelze FETCH_XYZ předávat tímhle způsobem. řešením, pokud má vůbec smysl to řešit, by asi bylo přidat Connection::setFetchMode()... co ty na to?

[dg]

Podle mě to nemá smysl řešit.

[dg]

ping @hrach - co si o tom myslíš?

[hrach]

Tezko se mi orientuje, jestli odkazovany paranoiq@0dd2e75 je presnou implementaci RFC. Budu spis reagovat na RFC.

• nemam rad, kdyz si z neceho muzu prilis vybrat, toto je presne ten pripad, kdy nevim, co chci. proto jsem zatim nikde na tento RFC a pullrequest nereagoval.
• pridani interface (a moznost vymenitelnosti) mi prijde vcelku zbytecna dekompozice.
• v RFC se mluvi o rezimu placeholder a alternate. Neimplentoval bych to takto, naopak bych to udelal jako v dibi. Tzn. vzdy pouzit otaznik jako placeholder, a podle poctu otazniku v statementu vyzadovat pocet argumentu. Melo by to vsechno pekne fungovat se zpetnou kompatibilitou, zaroven umoznit pridavat hodnoty drive nez na konci.
• sql fragment (z RFC) jiz neni treba
• nejslozitejsi casti mi pripada zpracovani poli. Zde vaham. V ndb nemame zadne modifikatory, ktery by rikali, co s tim, takze to vsechno zavisi na parsovani vyrazu pred placeholderem. Tomu bych se rad vyhnul, u SqlBuilderu jsem si toho ted uzil dost, ackoliv, samozrejme je mozne tu logiku presunout z nej... Ale asi proc ne :)

Konkretne bych tedy postupoval ve vice krocich:

• pridat podporu pro placholdery mezi casti sql dotazu
• vylepsit detekci formatovani pole

[dg]

Implementoval jsem to ve stylu dibi, tj, počet otazníků ve výrazu určuje, kolik následujících hodnot jsou parametry.