tiny ‘n’ smart
database layer

Odkazy: dibi | API reference

Oznámení

Omlouváme se, provoz fóra byl ukončen

DibiDataSource

před 11 lety

LM
Člen | 206

…je moc pěkná a užitečná věc, ale schází mi možnost nastavit podle čeho se mají záznamy řadit, nešlo by toto přidat?

před 11 lety

David Grudl
Nette Core | 6806

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) ...

před 11 lety

LM
Člen | 206

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áří?)

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

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

A co rozšíření IDataSource? pokud bych chtěl vytvořit DataGrid který by pracoval jen s tímto rozhraním a měl by umět i řazení tak si s ním nevystačí, leda jít cestou .NET frameworku, událost třeba onDataSort kde se dataSource seřadí a poté přebinduje…

před 11 lety

Villem
Člen | 19

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)

před 11 lety

LM
Člen | 206

Villem napsal(a):
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.

Přesně tak vrátí počet z původního dotazu (cachováno) a podle mě je to špatné chování, třeba stránkování pak může zobrazovat více stránek než jich ve skutečnosti je…

před 11 lety

Villem
Člen | 19

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.

před 11 lety

Villem
Člen | 19

Když tak sleduji diskuzi na https://forum.nette.org/…iewtopic.php?… možná bude skustčně lépe nechat count() vracet počet řádků celého výsledku. Ale přimlouvám se za to aby některá funkce vracela i počet všech řádků v iniciačním dotazu.

před 11 lety

Villem
Člen | 19

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?

před 11 lety

David Grudl
Nette Core | 6806

Villem napsal(a):

Takový malý snad bug repport.

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?

Díky za report, chování upravím.

před 11 lety

David Grudl
Nette Core | 6806

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

před 10 lety

arron
Člen | 462

Mozna trochu OT a dost mozna budu vypadat jak lama, ale…

Od te doby, co jsem nahlednul pod poklicku OOP, tak jsem nabyl dojmu, ze preferovany pristup (a ted tedy konkretne k databazi) je ala DibiTable a tak nejak jsem se vzdycky snazil k tomu tak pristupovat (kazdy zaznam je objekt, ktery se umi postarat sam o sebe, popripade co tabulka to trida atd…). 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. A proto bych se chtel zeptat, jaky je tedy nejlepsi pristup? Jak rozumne reprezentovat jednotlive tabulky a zaznamy? Jak navrhnout pristup k databazi, aby se dal snadno rozsirovat?

Doufam, ze se rozvine nejaka diskuze a predem vam vsem dekuju za nazory:-)

před 10 lety

David Grudl
Nette Core | 6806

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.

před 10 lety

paranoiq
Člen | 388

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

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

před 10 lety

arron
Člen | 462

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?

před 10 lety

Villem
Člen | 19

arron napsal(a):

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?

Např. pomocí zmíněného DibiDataSource. Text základního dotazu je „na jendom místě“. Pokud provedu změnu názvu sloupce v DB tak jenom přepíšu ten dotaz a pomocí AS si ten sloupec prejmenuju zpět … žádná změna v dalším kodu.

Nebo nepoužiju přímo tabulku, ale pohled. Potom při pokusu o alter table dostanu chybu se seznamem pohledů, které jsou tím postiženy.

před 10 lety

arron
Člen | 462

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

před 10 lety

phx
Člen | 652

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.

před 10 lety

David Grudl
Nette Core | 6806

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.

před 10 lety

Honza M.
Člen | 1674

Mohl bych malý feature request? Nešlo by umožnit vybírat sloupce takto $dataSource->select("sloupec1,sloupec2,sloupec3")? Psát tam klasické pole je dost otravné…

před 10 lety

Jod
Člen | 703

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

před 10 lety

Honza M.
Člen | 1674

Dokumentaci myslíš api? Koukal jsem trochu do zdrojáku a ten parametr string bude asi určen pro situace, kdy chci vybrat jen jeden sloupec nebo co. To ale není moc časté použití, řekl bych.

před 10 lety

Jod
Člen | 703

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