DibiDataSource

V poslední revizi doznal DibiDataSource podstatných změn. Jednak je plně integrován s DibiConnection ($conn->dataSource('SELECT * FROM table') vytvoří DibiDataSource) a také DibiFluent (lze mezi nimi převádět metodami toFluent(), toDataSource()). Především ale lze vybírat sloupce, řazení, přidávat podmínky a limity:

$conn = dibi::getConnection();

$dataSource = $conn->dataSource('SELECT * FROM table WHERE active = 1'); // vrátí DibiDataSource
$dataSource->orderBy('name')->orderBy('title', Dibi::DESC);
$dataSource->applyLimit(10, 20);
$dataSource->where('mode=%d', $mode);

foreach ($dataSource as $row) ...

LM napsal(a):

Pěkné, akorát mi tam moc nesedí to where, zanáší to SQL někam kam podle mě nepatří (tohle už by mělo specifikovat to co ten dataSource vytváří?)

Ale SQL je dle mého výhodný pro popis fitru. Myslím tím tím stejný datasource pro zobrazení všech položek, jako pro zobrazení jenom jedné s daným id, jako pro zobrazení položek slpnující danou podmínku. K čemuž where potřebuješ. Na drou stranu to znamená že jména sloupců toho základního selectu se stanou veřejným rozhraním modelu. Ale SQL bylo pro zadávání takovýchto konstrukcí navrženo. Já bych se mu nevyhýbal za každou cenu.

$dataSource = $conn->dataSource('SELECT * FROM test');
echo count($dataSource);

$dataSource->where('id < 5');
echo count($dataSource); // vrací stejný počet

Pokud jsem to dobře pochopil tak $datasource->count() vrátí vždy počet záznamů původního dotazu (kterým byl DS inicializován) a nebo si prostějenom pamatuje výsledek od prvního volání (musím odzkoušet). Pokud by se hlasovalo tak jsem pro první variantu.

Editoval Villem (6. 2. 2009 14:23)

No to asi záleží na názoru. Mě to připadá logické, protože to count me spočítá velikost toho zdroje. Ale chápu, že opačný pohled má něco do sebe. Nicméně mi připadá, že se k tomu hodí spíše Fluent než DS. Tem mi připadá jako takový zabalený databázový pohled.

Takový malý snad bug repport.

Pokud DataSource nenastavíme žádné where tak se použije hodnota WHERE 1. Výsledný dotaz vypadá nějak takto

SELECT *

FROM (
SELECT *
FROM Table) AS t

WHERE 1

Používám databázy postgre, která mi ale vynadá, že WHERE potřebuje booleovskou hodnotu jako parametr a ne integer. Nebylo by tedy možné nahratit onu 1 hodnotou true dle zvoleného driveru?

Chování jsem opravil, count nyní vrací skutečný počet prvků, vnitřní dotaz spočítá getTotalCount().

arron napsal(a):

Ted najednou jsem postaven pred velky otaznik, protoze jeden z nejlepsich php programatoru v republice (nedovazuju se porovnavat v sirsim meritku) tento pristup v podstate zavrhnul.

Sice nevím, koho myslíš, ale budu skromně předpokládat, že to asi budu já :-)))

Rozlišil bych názor na ORM (v tom se můžeme samozřejmě rozcházet) a podobu třídy DibiTable, která potřebuje další vývoj a ten je při zachování zpětné kompatibility nemožný (v tom se nejspíš shodneme). Proto jsem plánoval a dnes i provedl to, že jsem DibiTableX vyčlenil z distribuce a lze ji stáhnout samostatně. Může tak vzniknout více rozdílných verzí třídy, třeba jedna využívající nových vlastností PHP 5.3.

A proto bych se chtel zeptat, jaky je tedy nejlepsi pristup?

Každému může vyhovovat jiný, tohle je věc názoru. Mě se nejvíc líbí pracovat s databází přímo, třeba pomocí DibiDataSource, a berličky typu ORM (DibiTable) úplně vynechat.

myslím, že použití či nepoužití ORM není ani tak věc názoru jako spíš situace. pokud potřebuji dělat úpravy na jednotlivých záznamech (ruční vkládání či editace položek), tak je použití nějakého ORM asi nejjednoduší možnost. když chci zobrazit či zpracovat hromadu dat, tak se mu zdaleka vyhnu

To ale v konecnem dusledku znamena, ze temer vsude se bude vyvijet jak nejaka ORM metoda pristupu k databazi (typicky administrace), tak potom nejaky dalsi zpusob (‚front-web‘). Nebo se mylim?

Každému může vyhovovat jiný, tohle je věc názoru. Mě se nejvíc líbí pracovat s databází přímo, třeba pomocí DibiDataSource, a berličky typu ORM (DibiTable) úplně vynechat.

A jak potom resis, kdyz se Ti nekde neco zmeni (co ja vim, nazev sloupecku…)? Musis hledat kde vsude v kodu je pouzity a vsude ho menit? To je totiz podle me jeden z duvodu, proc chteji vsichni pouzivat DibiTable, pocit, ze kdyz se neco zmeni, zmenim to jenom na jednom miste (coz je v podstate obecna snaha, ze jo). Ja chapu, ze DibiTable neni samospasitelna, ale jak tedy udrzet rozumnou ‚menitelnost‘ kodu jinak?

Tak jsem nakonec ve svych uvahach dospel k tomu, ze se to proste musi v prve rade poradne navrhnout a rozmyslet:-)

phx napsal(a):

Mel bych jednu prosbu. Bylo by mozne aby metoda setOrder akceptovala i bool pro smer. Myslim true pro ASC a false pro DESC. Prijde mi to praktictejsi.

Praktičtější to moc není, vede to k méně čitelnému kódu. Přesto to funguje, zkus.

V dokumentácii vidím, že berie aj tvoju konštrukciu. Skúšal si to?

Aha už to vidím. Ja zase radšej píšem do pola :)