Téměř v cíli: dibi 0.9b

>> To byste se nedostali do nebe!
Pokud narážíš na Švejka, tak tam je: To by vás ani nesměli pohřbít na hřbitově! (Scéna s Janem Marvanem jako velitelem četnické stanice a jejich posluhovačkou)

Jinak dibi licence vypadá velmi dobře, protože nejde o úchylné GPL ale rozumné BSD

Tejto vety sa stale desim: Hledání správné‚n‘kůl syntaxe trvalo nesmírně dlouho a dodnes nejde o uzavřenou kapitolu vývoje.

BTW: ako to, ze tato kadibudka nema PR, je v tom nejaka certovina?

hip hip hurá, na tohle se těším víc než na Vánoce :)

No ještě dokončit Nette a bude to paráda

Super práce, díky.

#4 Milan: Nechcete někdo přeložit článek http://phpfashion.com/…bazovy-layer do angličtiny a přidat k němu zpracování odpovědi z tohoto článku?
Ať má David čas na programování? 

S tim fetchAssoc je to skvělý nápad. Před prvním použitím bych si to sice musel znovat přečíst, ale chápu, o co ti jde. A věřim, že to rychle přeleze do krve.

V této souvislosti mě napadlo toto. Když má člověk model typicky jako objekty, tak by se mu hodilo aby tam bylo i něco jako fetchObject(), které by nacpalo výsledek do atributů objektu.
Což by chtělo zas nějak pěkně pořešit výsledek ze spojených tabulek, že se třeba instancují objekty do pole…

Příklad by pak mohl vypadat takto:

$res = dibi::query('
  SELECT customer_id, customers.name, order_id, orders.number, ...
  FROM customers
  INNER JOIN orders USING (customer_id)
  WHERE ...
');

Získaní dat:

$customers = $res->fetchObject('customer_id,order_id');

Struktura metody fetchObject by mohla vypadat nějak takhle:

function fetchObj() {
$customers = array();
$i = 0;
while ($row = $this->res->fetch()) {
  $customers[$i] = new Customer($row['customer_id']);
/* nebo variata takhle:
  $customers[$row['customer_id']] = new Customer($row['customer_id']);
*/
  $customers->setName($row['name']);
  $customers->orders = array();
  for ($j = 0; $j < pocet objednavek; $j++) {
    $customers->orders[$j] = new Order($row['order_id']);
    $customers->orders[$j]->setNumber($row['number']);
  }
  $i++
}
return $customers;
}

// budeme jej procházet takto:
foreach ($customers as $customer) {
   foreach ($customer->orders as $order) {
       ...
   }
}

Ještě by se mohla mít metoda fetchObj() volitelné parametry jestli instancovat třídy (a jaké na které idčka) pomocí new, nebo jestli získat objekt pomocí (tovární) metody. A které atributy nastavit set metodama a které narvat přímo do konstruktoru.

Neni to ORM a přitom dostaneš výsledek jako bys použil ORM A nemusíš se trápit s ruční jednotvárnou prací vytvářenim objektů po každym selektu (opruz 

Pak by byl new Order nastolen

Mám takový pocit, že už nejsi tak kategoricky proti ORM jako na začátku. Že by jsi při svém vývoji dibi narazil na její omezení? 

#7 veena: to co navrhuješ je ORM, ne že neni.

[12222] nejsem si jistý, jestli to, co píšete, se dá hodit právě na dibi. Jak tuhle knihovnu chápu, tak si můžete napsat libovolný sql příkaz.

S různě formátovanými daty (i datumy) v různých db enginech by právě mělo dibi pomoci. Viz odstavec modifikátory v dokumentaci dibi na:
http://phpfashion.com/…bazovy-layer
Jasně asi Vám to příliš nepomůže s procedurami, rozšířeními SQL jazyka apod. To ale Vámi zmiňované knihovny také ne.

PDO je povedený nástroj v php. Ale není to database abstraction layer ale data-access abstraction layer. Takže s úpravou sql dotazů pro různé db enginy vám nepomůže.
Nicméně jak David dneska popsal, zaimplementoval i experimentální adaptér na PDO.

Ze začátku jsem byl k dibi skeptický. Nyní ale oceňuji dobrý návrh a užitečné funkce, které programátorům šetří čas. Pokud myslíte, že vám ne, tak to samozřejmě nepoužívejte.

#9 rarouš: Já myslim, že ne. ORM by mělo fungovat obousměrně. O->R i R->O. V ORM nepíšeš žádný SQL dotaz, ale voláš metodu mapperu, která pozná, jaké SQL má zkonstruovat.

To, co navrhuju, je „jen“ jednosměrný mapper výsledku do objektů. R->O.

„Po dotazu následuje odpověď a tou je buď TRUE (u příkazů INSERT, UPDATE, …)“

A nebylo by lepší vracet automatické ID vloženého/upra­vovaného záznamu, existuje-li? Docela se to hodí v případě, kdy s ním potřebuju dál pracovat (vložím záznam a pak chci vložit další záznamy do jiné tabulky, která je s tou původní v relaci 1:N nebo N:M).

Vypadá to fajnově, nemůžu se dočkat, až vyzkouším kombinaci Dibi + Texy + Nette. Nemáš v záloze ještě nějaký sexy projekt? ;)

#1 Jakub Lucký: JJ, GPL je úchylné, pokud není (např. jako u Texy!) možnost použít jinou licenci v uzavřené aplikaci… Pak má člověk chuť aplikaci pro jistotu nepoužít, protože pak není možnost distribuovat aplikaci jinak, třeba komerčně pro klienty s uzavřeným zdrojákem a tak.

#6 veena: Já bych to klidně udělal, jenže problém je v tom, že anglicky nějak moc neumím, takže bych Davidovi udělal leda ostudu 

DGX, můžu se zeptat jaké jsou ty problémy které ORM přináší? Momentálně jsem ve stadiu téměř nekritického nadšení a upravil jsem si jeden malý ORM framework, ale rád bych věděl co mě čeká :)

#2 Ivan: obáváš se toho kvůli nekompatibilitě? Už mi dibi běží na tolika projektech, že bych do toho nešáhl.

#3 Tom: ovšem to bude chyba ve výchově a rodiném zázemí 

#6 veena: vydržte, chodili by mi sem lidi ;)

#10 veena: joj, než jsem si všiml, že reaguješ, tak doběhl Indiana Jones a pána smazal… On je někdy strašně ukvapený, kluk ušatá.

#12 David Majda: nad tím jsem váhal, ale nakonec ve prospěch čitelnosti kódu aplikací, které dibi používají, to zavrhl. Nehledě na další problémy s tím spojené (jak zjistit který SQL dotaz ID vrací, co když je dotazů víc, jak to řešit u databází s odlišným přístupem, atd). Nad čím ale uvažuju, tak je fluent interface a vracení $this.

#13 tark: obvykle je nejjednodušší napsat autorovi a domluvit se s ním. GPL vůbec nezavrhuji, jen mám pocit, že se pro tento typ knihovny nehodí.

#14 Keff: to je značně subjektivní. Souvisí to s pocitem, kdy se dostaneš do situace, kterou bys uměl hned a snadno vyřešit v SQL, ale s ORM je to hodně složitější. Nebo budeš muset zoptimalizovat operace nad databází, v SQL by věděl hned, ale s ORM to třeba vůbec nepůjde.

#7 veena: tak teď si ale držte klouboky

// znáte od tvůrců jazyka JavaScript
function DibiResult_prototype_fetchObject(DibiResult $obj, $param, $param, ...)
{
    $customers = array();
    ... // Veenův kód
    return $customers;
}

$res = dibi::query('
    SELECT customer_id, customers.name, order_id, ...
    FROM customers
    INNER JOIN orders USING (customer_id)
');

$customers = $res->fetchObject('customer_id,order_id');
// $customers je naplněn tvou metodou!

Jinými slovy, můžete si přidávat vlastní metody do každé třídy dibi (tedy nestatické). Naznačoval jsem to na frameworkové konferenci, v dibi už to běží naostro.

Takže pokud ráčíte používat třeba novou fetch metodu, netřeba mě přesvědčovat o její implementaci, snadno si ji doplníte sami 

#15 David Grudl: Jo, to je pravda, to mi nedošlo ;)

#16 David Grudl: Fajné a pěkné ;)

Ta funkce fetchAssoc vypadá opravdu zajímavě. Nikdy mě nic podobného nenapadlo.

Problematika DB se nám teď, ze dne na den, posunula na novou úroveň. Fascinující. Velmi se těším:-) – Jestli se o někom z naší republiky dá říct že UMÍ programovat v PHP, tak je to David – On není jako my ostatní, co se v tom jen patláme:-)…on programuje vysoko, kam mi nedosáhneme – o důvod víc, proč ho podporovat:-) – jen tak dál!!

#16 David Grudl: kurňa, teď nevím, jestli mám jásat, nebo plakat, že si to musím naprogramovat sám ;-D

Čo mi dáte, keď nad DiBi spravím pekný, malý a šikovný OR mapper?

#21 johno: To je co, smím-li se zeptat? ;)

#21 johno: polovina ekonomického zisku z dibi je tvá

(pak ti pošlu své číslo účtu, abysme se vyrovnali)

#22 tark: Počkejte, ttto to jsem se měl přece zeptat já.

#23 David Grudl: Pričom, ten prevod peňazí by ma stál asi najviac.

#21 johno: johno podvádí, von už to má vymyšlený dopředu 

P.S. jdi do toho!

#12 David Majda: To co navrhuješ není zase tak triviální. Některé DB systémy jsou takovou informaci schopny vracet, ale bohužel najdou se i systémy, které pokud tě ID zajímá musíš ho nejdříve získat a poté teprve s ním pracovat, tzn. musíš ho použít přímo do insertu.

Aktualizace: do článku jsem doplnil odstaveček na téma „dibi vs. PDO“ a pět praktických tipů ze života dibaře

Davide, moc se mi to líbí! Zatím jsem to nikde nepoužil, ale už se vyloženě těším. 

Kdyby se rozdávali Nobelovy ceny za PHP, byl bych svými všemi 104 klávesami pro udělení té ceny Tobě.

Ahoj, nevim jestli to tu uz nekdo napsal, nebo jestli jste na to uz nahodou neprisel…ale mam pocit, ze jsem nasel malou chybu ve zdrojovem kodu dibi. V souboru DibiTranslator.php na radku 116 jsem presvedcen, ze by misto „REPLAC“ melo byt „REPLACE“.

S pozdravem
Tomas Lembacher

#11 veena: ORM je proces při kterém mapuješ relační data na objekty či naopak. Je celkem fuk, jestli k tomu použiješ nějakej framework (mapper) nebo všechno uděláš růčo. Tak či tak jde o ORM.

Jak je to s chybovosti? Docela me zklamalo, kdyz jsem zahodil PHPDoctrine, protoze jsem prisel kazdou chvili na chyby, ktere me nastvaly. Znate to: Pouzivate cizi kod, nevite jestli chybu delate vy a nebo knihovna ⇒ nekolik hodin v haji kvuli blbosti.

Chtel jsem se proto zeptat o kolika chybach vis, resp. kolik jich ocekavas?

#29 Tomas Lembacher: díky za report, ale chyba to není.

#31 Washo: dibi sem o nějaké věděl, tak bych ji už opravil

Ahoj.

podporuje to prepared statements? Mám na mysli hlavně Asistenta?

#33 Pavel Stehule: prepared statements podporované nejsou, vysvětlení zde. Technicky není problém je do knihovny přidat, ale smysl v tom nevidím.

(prepared statements prý v MySQL zhoršují výkon)

Velmi pěkné!

Mě se ještě často hodí funkce, co vrátí jednu jedinou hodnotu z SQL výsledku, něco jako

$count = dibi::fetchVa­lue(„SELECT count(id) FROM …“);

žeru MyDateTime :))

#35 Michal Till:

// užitečná je i metoda pro získání hodnoty prvního sloupce:
dibi::query('SELECT [name] FROM ...')->fetchSingle();

#35 Michal Till: dibi::fetch($sql), dibi::fetchSin­gle($sql) a dibi::fetchAll($sql) tam je

#36 PIF: tak dobrou chuť ;)

Nefungoval mi driver postgre a tak po úprave súboru v drivers, konkretne >

$this->connection = @pg_pconnect("host=".$config['host']." user=".$config['username']." password=".$config['password']." dbname=".$config['database'], PGSQL_CONNECT_FORCE_NEW);

to už ide … neviem ci to bolo spôsobené len tým že som sa pripájal na iný host alebo či si len robil dáke zmeny a na tento driver si zabudol.

#39 Luke: no, já předávám funkci pg_connect přímo ten poskládaný connection_string, ale asi by nebylo špatné přidat i skládací funkci. Tak zkus aktuální verzi:

dibi::connect(array(
    'driver'     => 'postgre',
    'host'       => 'localhost',
    'port'       => 5432,
    'dbname'     => 'mary',
));

No já tedy nevím, ale „správnou a cool syntaxi“ psaní SQL dotazů bych si představoval úplně jinak. O asistenci se taky moc mluvit nedá.

Když už, tak bych si nepomáhal jednou metodou, ale používal bych jich víc:

dao->getAllRows("orders", Array("id", "date"));
// = select id, date from orders
dao->getSomeRows("orders", Array("id", "date",), "customer_id", 6);
// = select id, date from orders where customer_id = 6)

A pokud se týká zpracování výsledků, tak to by měla být starost jiné třídy, ne db layeru. Přičemž rozhraní mezi třídami tvoří result.

echo formatter::Table(dao->getRows(...));

#41 Mastodont: jenže to už není „psaní SQL dotazů“. Všimni si podstatné věci – tvůj zápis je delší a mnohem méně intuitivní, než pod tím vygenerovaný SQL příkaz. Proto to hodnotím jako krok zpět (viz Zlo si říká Database Abstraction Layer). Jdu jinou cestou, která tu přímočarost SQL příkazů zachovává.

Experimentuji taky s více inteligentním zapouzdřením příkazů SELECT, INSERT nebo UPDATE, vlastně už pár let, ale stále nejsem spokojen.

ad zpracování výsledků: dibi samozřejmě končí u poskytnutí resultu, výsledky nezpracovává.

Fatal error: Class ‚NClass‘ not found in C:\…\dibi.com­pact.php on line 326.

Kde vezmu NClass? Bývalo to v souboru NObject.php, ale teď už se asi NClass nevyrábí…

#43 Honza M.: divné, nic se totiž neměnilo. Zkus stáhnout aktuální verzi. Podívat se, jestli to nekoliduje s jinou třídou, jiným souborem…

(update: NClass je nyní v samostatném souboru, ale stále součástí dibi.compact.php)

#44 David Grudl: Tlouklo se mi to se souborem NObject.php z NFormů…
Doufám, že tyhlety NObejcty a NClassy od dibi a NForm jsou navzájem kompatibilní Zatim to vypadá dobře.

#40 David Grudl: To som samozrejme skúsil a nešlo to, overil som to teraz ešte raz … podla mňa je asi problém v skladaní toho connection stringu, kde názov databázy je s podtržítkom … aspon z vyhodenej výnimky tomu tak rozumiem …

A neviem ci mam niekde chybu, ale nevracia mi insertId posledne idcko, ak je postgre verzia 8.0 …

#47 Luke: v postgre se používá dibi::insertId($sequenceName);. Každopádně si stáhni poslední verzi, v rev. 99 byl bug.

Ahoj,
mám takovej problém s regexp, tak mi tu snad někdo poradí. Přepsal jsem si dibi do C++, ale umí to zatím jenom nativeQuery. Chtěl bych udělat i query, ale nemůžu se poprat s jedním použitým regexp v C++. Konkrétně se jedná o tenhleten:

preg_replace_ca­llback(
‚/(?=|\[|\'|"|%)(?:(.+?)`|\[(.+?)\]|(\‘)(­(?:\‚\‘|[^\‚]))\‘|(„)((?­:""|[^“]))„|%(el­se|end)|%([a-zA-Z]{1,3})$|(\‚­|“))/s‘,
array($this, ‚cb‘),
substr($value, $toSkip)
 );

umístěný v Translatoru. Díky za každej tip, kterej mi to pomůze vyřešit.

Ahoj, jako vždy mám geniální nápad… Co kdyby dibi umělo vybírat více položek podle pole.

$res = dibi::query("select * from [table] where [id]=%or", array(1, 6, 7, 4));
// select * from `table` where (`id`=1 or `id`=6 or `id`=7 or `id`=4)

// nebo

$res = dibi::query("select * from [table] where [id]=%and", array(1, 6, 7, 4));
// select * from `table` where (`id`=1 and `id`=6 and `id`=7 and `id`=4)

Jistě by to bylo prospěšné, teď to řeším jakousi externí funkcí.

$res = dibi::query("select * from [table] where " . sqlOr("id", array(1, 6, 7, 4))); // nebo sqlOr("id", "1,6,7,4");

#50 Honza M.: to lze:

$res = dibi::query("
select *
from [table]
where [id] IN ", array(1, 6, 7, 4)
);

Mám nějakou možnost zjistit (nejlépe při volání dibi::dump()), na kterém řádku v mém kódu byla volána metoda dibi::query(), resp. dibi::fetch() a ostatní?

přidávám si (za určitých podmínek pro testování) handler

function dumpAfterQuery() {
        dibi::dump();
}

a tam by se toto značně hodilo

#52 Finwe: zkus analyzovat debug_backtrace.

#53 David Grudl: No jasně, tam je pod klíčem 5, myslel jsem, jestli to dibi neumí nějak interně.

Systém handlerů je boží a bude ještě víc, až bude hotov a zdokumentován :) Takhle se mi ta query dumpuje dvakrát…

Zatím asi ideální řešení na #52 Finwe: je subclassovat dibi. Například takto:

class db extends dibi
{

        public static $debug = false;

        public static function setDebug($debug = true)
        {
                self::$debug = $debug;
        }


        public static function query($args)
        {
                $return = parent::query($args);

                if (self::$debug) {
                        $bt = debug_backtrace();

                        echo '<pre>';
                        echo $bt&#91;0&#93;['file'] . ':' . $bt&#91;0&#93;['line'];
                        echo '</pre>';

                        dibi::dump();
                }

                return $return;
        }
}

pokud je pak v kódu nastaveno db::setDebug(), po db::query() se vypíše dump spolu se souborem a číslem řádku.

bohužel jsem ještě nepřišel na to, jak zajistit, aby se to tak chovalo automaticky i pro metody db::fetch() a ostatní :(

ahoj, nechcem ti to tu meniť na poradňu, ale s takýmto errorom si ako poradím? :)

Fatal error: Interface 'Countable' not found in .../www_root/dibi.compact.php on line 206

všetko čo som o interface Countable vygooglil je, že releasol vo verzii 5.1. Hmm phpversion() mi vráti 5.2.4. Niečo som zabudol, alebo som hlúpy? :). Na localhoste mi to beži, na webe nie.
Všetko čo robím je: dibi::connect(…)

Ďakujem za prípadné odpovede.

#56 miloš: leda že jde o nějaký obskurní hosting, na kterém není SPL. Poznáš to z phpinfo()

Podle toho, co jsem zjistil, načítá dibi drivery sama a používá k tomu class_exists – tato funkce ovšem defaultně používá autoload, a to může aplikaci s pro dibi netypickým formátem autoloadu solidně zmást. Pokud tedy nemám explicitně spolu s dibi requirovat php soubor ovladače, nebylo by lepší místo

if (!class_exists($class)) {

použít

if (!class_exists($class, false)) {

?

Jde o soubor DibiConnection.php:77 rev. 104 (v revizi 110 je to stejně)

#58 Finwe: to je správná připomínka, false tam skutečné chybí. Jen nějak nerozumím tomu zmatení a netypickému formátu autoloadu…

#59 David Grudl: Zmást = nechat vyhodit fatal error A netypický = „blbý“ (například ve stylu „očekávám třídu ve formátu {classname}.class.php a ne jinak“).

Nic víc

Ahoj, narazil jsem na drobný problém, a sice, jak se při výjímce dostat k číselnému kódu poslední chyby? Konkrétně u ovladače pro sqlite. Jde o PHP funkci sqlite_last_error, eventuelně metodu SQLiteDatabase->lastError(). Prolezl jsem zdrojáky i dokumentaci API, ale žádnou cestu jsem nenašel :(