Tharos / LeanQuery

www.leanmapper.com
MIT License
6 stars 5 forks source link

namiesto %s %i %d... zadavat len ? #8

Open achtan opened 10 years ago

achtan commented 10 years ago

cize npar: miesto ->where('e.id = %d', $id) by sa pisalo len ->where('e.id = ?', $id)

Tharos commented 10 years ago

Tohle by určitě chtělo, díky za podnět.

Píšu si na seznam věcí k implementaci a jelikož to myslím nebude vůbec nic náročného, věřím, že to spatří světlo světa brzy.

mibk commented 10 years ago

Když jsem se o toto snažil já, narazil jsem na několik problémů. Řekněme, že nejspíš chceme za otazník dosadit takový %placeholder, který bude odpovídat typu oné property v entitě.

Řešil jsem tedy např. jakým způsobem poznat, který otazník patří ke které konstrukci alias.property (tedy např. e.id). Nakonec jsem využil pouze hloupý předpoklad, že placeholder vždy následuje za přísloušnou property. Uživatel by ale teoreticky mohl zadávat něco jako ->where('? = e.id', $id), kde už by to neplatilo.

Dalším problémem, který mě zrovna napadl, je, že typ property se nemusí shodovat s typem v databázi. Property může být třeba typu array, které se pomocí passThru transformuje do stringu. Asi by musel existovat nějaký oficiální způsob, jak specifikovat typ v databázi, pokud se liší. Mohl by to být nějaký custom flag využívaný jen LeanQuery (já např. custom flagem řeším datetime vs date, ačkoli z mého nynějšího pohledu asi ne moc šikovně), ale mně by se možná líbil více nějaký oficiální způsob přímo v Lean Mapperu -- přijde mi to jako docela užitečná věc, která by mohl přinést nějaké výhody.

Nebo to jde vše jednodušeji a já to pouze nevidím?

Pokud bychom se dohodli na dali do kupy nějaké myšlenky, asi bych si mohl najít čas připravit pull request.

Tharos commented 10 years ago

Já si myslím, že to nebude náročné na implementaci, a to proto, protože já navazování parametrů v Lean Query kompletně deleguji na dibi. V podstatě jedinou záludností je při zpracovávání parametrů where rozlišovat, co je parametr, který se má někam navázat, a co už je další část dostazu. Kopíruji logiku, kterou používá dibi – když se v parametrech objeví část dotazu se třemi placeholdery, další tři parametry jsou chápány jako navazované parametry atp.

No a v tomhle duchu by mělo být jednoduché začít vnímat jako placeholdery navíc i otazníky, nejen %....

mibk commented 10 years ago

Tak jsem to buď nepochopil, nebo se každý bavíme trochu o něčem jiném. Jestliže se vše deleguje na dibi (čemuž rozumím), tak o dosazování parametrů za placeholdery se stará pouze dibi. Myslel jsem si tedy, že naší starostí je převést konstrukci ->where('e.id = ?', $id) na ->where('e.id = %i', $id) a nahradit tedy ? za takový placeholder, který bude odpovídat typu property e.id (tedy při [int => %i, string => %s, DateTime => %t] a podobně).

Tharos commented 10 years ago

Fígl je v tom, že ono stačí převést ->where('entity.property = ?', $value) na ->where('table.column = ?', $value). :) Dibi ty otazníky umí zpracovat.

Viz například tento článek: „Moc se to neví, ale místo přemýšlení, který modifikátor použít, můžete obvykle použít otazník.“

Tahle skutečnost tuhle issue řádově zjednodušuje.

mibk commented 10 years ago

O tom, že se dá použít otazník, vím, ale myslel jsem si (a teď jsem to i zhruba vyzkoušel), že se poté s parametrem zachází pouze podle typu onoho parametru. Pokud by tedy e.id byl v databázi int a hodnota parametru $id by byl string, výsledný dotaz by byl WHEREtable.id= '4'.

Že to nejspíše pro většinu dotazů nebude důležité, je druhá věc. Já jsem však celou dobu řešil volbu placeholderu podle typu property a ne podle typu parametru. Zvolil by se poté např. správný %t nebo %d podle typu property, protože z DateTime se toho více poznat nedá.

Abych řekl pravdu, čisté delegování na dibi i s otazníkem jsem očekával, že by mohlo fungovat už nyní. Až teď jsem se koukal do zdrojáku, že tam máš regulární výraz, kterým formát funkce andWhere omezuješ. Dokud jsem se nekoukl do zdrojáku, myslel jsem, že pouze vyzobáváš konstrukce foo.bar.