dibi fórum

Cannot redeclare class NDebugger pri viacnasobnom pripojeni (Řešení potíží)

medhi — Thu, 02 Feb 2012 16:15:36 +0100

Krása

Cannot redeclare class NDebugger pri viacnasobnom pripojeni (Řešení potíží)

David Grudl — Wed, 01 Feb 2012 21:49:31 +0100

díky, fixed

dibi::update bez druhého parametru (Obecná diskuse)

kopec — Wed, 01 Feb 2012 16:42:05 +0100

Zdravím, nešlo by u update() nevynucovat druhý parametr a přidávat hodnoty až zpětně pomocí set()?

Cannot redeclare class NDebugger pri viacnasobnom pripojeni (Řešení potíží)

Matúš Matula — Sun, 29 Jan 2012 18:26:01 +0100

Myslim, ze som narazil na bug, kt. sposobuje vynimku ‚Cannot redeclare class NDebugger‘ pri pokuse vytvorit nove pripojenie k db. Sposobuje to tento riadok http://api.dibiphp.com/…nel.php.html#52. Oprava by mala stacit takto:

<?php
if (is_callable('Nette\Diagnostics\Debugger::enable') && !class_exists('NDebugger')) {
        class_alias('Nette\Diagnostics\Debugger', 'NDebugger'); // PHP 5.2 code compatibility
}
?>

Vydána nová verze dibi 2 rc2 (Changelog)

Milo — Thu, 19 Jan 2012 11:22:19 +0100

Číslo 2.0 se líp pamatuje :)

Zkusil jsem novou verzi nasadit na několik projektů co mi běží. Většinou to bylo bez problémů, ale přeci jen jsem narazil na několik zádrhelů.

Jeden projekt mi běží na PHP 5.2 a Nette 0.9.6. Tam řval RobotLoader na DibiNetteExtension.php kvůli jmenným prostorům. Nebylo by lepší vytvořit třídy DibiNetteXxxx aby se zachovala PHP 5.2 kompatibilita? Např:

if (class_exists('Nette\Config\CompilerExtension')) {
        class_alias('Nette\Config\CompilerExtension', 'NetteDibiCompilerExtension');

} elseif (class_exists('CompilerExtension')) {
        class NetteDibiCompilerExtension extends CompilerExtension {}

} else {
        class NetteDibiCompilerExtension {}
}

// a následně
class DibiNetteExtension extends NetteDibiCompilerExtension
{
        ...
        ...
}

// A to samé pro IBarPanel

A pak jsem narazil na chybnou konverzi polí integerů v PostgreSQL. Popsal jsem tady

Bug report: Rozpoznávání datových typů (Řešení potíží)

Milo — Thu, 19 Jan 2012 11:03:54 +0100

Funguje to dobře. Zkusil jsem velká (nad PHP_INT_MAX) i hodně velká (300 cifer) čísla.

Narazil jsem ale na problém pole integerů v PostgreSQL, jsou převedeny na nulu. Např {10} nebo {{10},{20}}. Fixnul jsem to v pull requestu ale nevím, co na to ostatní drivery. Pokud je sloupec v postgresu pole, nativní typ začíná podtržítkem (_int8 _numeric ...).

dev 2010–04–22 – DibiRow is not longer ArrayObject descendant (Diskuse o vývoji Dibi)

David Grudl — Thu, 19 Jan 2012 05:47:35 +0100

Milanov napsal(a):

Petr Daňa napsal(a):

PHP Notice: Indirect modification of overloaded element of DibiRow has no effect in …

V poslední verzi (1.5rc) je stále stejný „problém“. Jedná se vůbec o problém, nebo o vlastnost a nic s tím nelze udělat?

Jedná se o vlastnost PHP, se kterou nelze nic udělat.

dev 2010–04–22 – DibiRow is not longer ArrayObject descendant (Diskuse o vývoji Dibi)

David Grudl — Thu, 19 Jan 2012 05:47:08 +0100

Voláním setRowClass(FALSE) si můžete nechat vracet pole.

Bug report: Rozpoznávání datových typů (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 05:40:38 +0100

Konverze už funguje jinak, přetrvává problém?

[Bug report] Modifikátor %like a jeho použití v poli (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 05:37:13 +0100

Mělo by to fungovat, ale je třeba použít korektní dibi::test("SELECT * FROM tabulka WHERE %and", array('name%~like~' => 'foo')); (tedy s %and).

driver mssql2005 neumí transakce, tady je patch (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 05:15:50 +0100

Dal jsem to tam.

DibiFluent, setType a Oracle – oci_execute(): ORA-00907: chybí pravá závorka (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 05:14:13 +0100

Použij from('tabulka')->execute(), nicméně v poslední verzi se detekce typů už provádí automaticky.

Dumpnutí celé databáze (záloha) (Obecná diskuse)

David Grudl — Thu, 19 Jan 2012 05:12:03 +0100

https://github.com/dg/MySQL-dump

feature request: Možnost nastavit RowClass u DibiFluent (Obecná diskuse)

David Grudl — Thu, 19 Jan 2012 05:02:39 +0100

Dá se to udělat pomocí $fluent->setupResult('setRowClass', '...')

formatDateTime – rozdílné formátování pro date a datetime (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 04:33:24 +0100

Konfigurační direktivu formatDate jsem přidal.

Návrat původního zdroje přes getResource (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 01:58:06 +0100

Auto-uvolňování se po zavolání getResultResource() vypne.

MySql version pro použití dibi (Obecná diskuse)

David Grudl — Thu, 19 Jan 2012 01:47:19 +0100

MySQL 4.1

Nadměrná spotřeba paměti dibi::query (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 01:46:02 +0100

Přetrvává problém u poslední verze? Detekování typů jsem zjednodušil.

Vydána nová verze dibi 2 rc2 (Changelog)

David Grudl — Thu, 19 Jan 2012 01:38:34 +0100

Mám docela problém se orientovat v desetinných číslech, takže finální verze nebude 1.5, ale 2.0. Alespoň bude zřejmé, že je kompatibilní s Nette 2.0 :-)

Problem s fetch v MSSQL při přihlášení pře PDO (Řešení potíží)

David Grudl — Thu, 19 Jan 2012 00:33:36 +0100

Tento problém by v poslední verzi být neměl.

Výběr databáze v již otevřeném spojení (‚No database selected‘) (Řešení potíží)

Šroubek — Sat, 14 Jan 2012 19:10:21 +0100

Jsem to ale trotl – tohle mě mohlo taky napadnout ;-) Helám v tom kdejaké složitosti a řešení je tak prosté. Moc díky.

Problém s includovaným připojením k databázi (Řešení potíží)

HosipLan — Sat, 14 Jan 2012 10:08:58 +0100

PHP není Python ;)

Problém s includovaným připojením k databázi (Řešení potíží)

Milo — Fri, 13 Jan 2012 22:44:36 +0100

Tohle není problém dibi, ale Tvého postupu. 2× načítáš soubor dibi.php. Všude používej require_once("dibi/dibi.php");

Problém s includovaným připojením k databázi (Řešení potíží)

taubda — Fri, 13 Jan 2012 19:35:06 +0100

Píšu blblosti –

require("dibi/dibi.php");
include "connect.php";  //V souboru, connect.php

Takže je problém stím include, né s require.

Výběr databáze v již otevřeném spojení (‚No database selected‘) (Řešení potíží)

paranoiq — Fri, 13 Jan 2012 10:00:58 +0100

USE `mydatabase`

Výběr databáze v již otevřeném spojení (‚No database selected‘) (Řešení potíží)

Šroubek — Fri, 13 Jan 2012 01:05:11 +0100

Ahoj,
jde nějak vybrat databázi v již otevřeném spojení?
Uvedu příklad co se mi nedaří:

$conf = array("driver"=>"mysql","host"=>"localhost","database"=>"mydatabase",...);
dibi::connect($conf); // zde jsem úspěšně připojen k databázi `mydatabase`
dibi::query("DROP DATABASE `mydatabase`"); // zde je asi pochopitelné že mě to od dropnuté databáze "odpojí" (spojení s DB serverem zůstává otevřené)
dibi::query("CREATE DATABASE `mydatabase`");

dibi::query("CREATE TABLE `mytable` (`id` INT(10),`value` VARCHAR(50))"); // ZDE mi to zahlásí chybu 'No database selected'

Stačí abych hned za CREATE DATABASE přidal dibi::disconnect(); dibi::connect($conf); a vše pak proběhne tak jak má (tabulka mytable se vytvoří). Ovšem zase mi to hlásí Warning: Cannot redeclare class NDebugger

Nebo můžu přidat název databáze přímo do dotazu CREATE TABLE mydatabase.mytable... a také to projde a tabulka se vytvoří (ale název databáze bych musel psát pak do každého dotazu).

Snažil jsem se najít něco jako dibi::selectDatabase("mydatabase"), zkoušel jsem použít dibi::activate(...), zkoušel jsem hledat zde na fóru i jinde na webu, ale nic se nesetkalo s požadovaným výsledkem :-( Prosím tedy o radu jestli nevíte jak to vyřešit, popřípadě co dělám špatně…

Díky za každou radu.

PS: Jen pro upřesnění proč dropuju databázi a pak ji zase vytvářím: mydatabase není databáze na které běží můj web, ale pouze testovací databáze na které budu spouštět databázové testy (něco jako Unit Testy, ovšem pro otestování tříd které přistupují k databázi). A před spuštěním testu potřebuji uvést testovací prostředí do výchozího stavu, což je prázdná databáze ve které si následně vytvořím potřebné tabulky naplněné testovacími daty individuálně pro každý test.

Problém v dotazu s create temporary table (Řešení potíží)

Milo — Thu, 12 Jan 2012 11:19:32 +0100

A jak to máš zapsané v dibi (pastni kód)?

Problém v dotazu s create temporary table (Řešení potíží)

vnovotny — Thu, 12 Jan 2012 08:55:41 +0100

Dobrý den, mám následující MySQL dotaz, přes SQLYog projde v pořádku, ale přes DIBI::QUERY() se vrací s chybou 1064. V čem může být problém? Všiml jsem si, že syntax highlighter laděnky nette ignoruje první řádek dotazu, ale to s tím asi nesouvisí…

P.S.: Samozřejmě se jedná pořád o tu samou DB

CREATE TEMPORARY TABLE `tmp` SELECT * FROM `report` WHERE `PeriodID` = 1;
UPDATE `tmp` SET `PeriodID` = 2 WHERE `PeriodID` = 1;
UPDATE `tmp` SET `ID` = NULL;
INSERT INTO `report` SELECT *FROM `tmp` WHERE `PeriodID` = 2

Trochu jsem to přepracoval a pořád totéž…

DROP TABLE IF EXISTS tmp;
CREATE TEMPORARY TABLE tmp SELECT `Data`, `PeriodID`, `Approved` FROM report WHERE PeriodID = 1;
UPDATE tmp SET PeriodID = 2 WHERE PeriodID = 1;
INSERT INTO report (`Data`, `PeriodID`, `Approved`) SELECT * FROM tmp WHERE PeriodID = 2

vyřešil jsem to nakonec v PHP, ale stejně by mě zajímalo, jak bych to vyřešil v DIBI jedním dotazem…

Vydána nová verze dibi 2 rc2 (Changelog)

PetrP — Thu, 12 Jan 2012 07:22:48 +0100

vrácená data z databáze se vždy převádějí na odpovídající datové typy (dříve se to povolilo pomocí detectTypes, teď je to výchozí chování)

A nejde to vypnout? Protože v případě že dibi používám jako nižší vrstvu v orm; tak podobné konverze jsou zbytečná zátěž.

Vydána nová verze dibi 2 rc2 (Changelog)

David Grudl — Thu, 12 Jan 2012 01:00:56 +0100

Doplnil jsem do dibi pár věcí, které se mi líbily nebo osvědčily v Nette\Database.

plná podpora pro univerzální modifikátor ? (tj. místo modifikátorů lze používat univerzální otazník)
vrácená data z databáze se vždy převádějí na odpovídající datové typy (dříve se to povolilo pomocí detectTypes, teď je to výchozí chování)
přidána třída DibiLiteral nahrazijící IDibiVariable
a podpora Debuggeru z aktuální verze Nette

Poprosil bych o důkladné otestování, aby se mohla vydat stabilní verze a tato řada uzavřít. Už bych nechtěl přidávat žádné nové featury, jen řešit bugfixy.

DibiFluent, LIMIT, OFFSET a fetch() (Řešení potíží)

kopec — Tue, 10 Jan 2012 10:54:32 +0100

Aye, moje chyba, koukal jsem na verzi a nějak mi nedošlo, že 1.5-rc1 není to samé, jako 1.5-rc, takže teď jsem updatoval a první problém je samozřejmě pryč.

//vyskytl se tedy nový ve formě fatálu, že třída DibiNettePanel neexistuje, ale to stačilo kdesi v DibiConnection tuto třídu načíst).

Druhý problém se vyřešil prvním, protože teď právě můžu udělat tu úpravu zdrojáku, kterou jsem předtím nemohl (limit se nepřepisoval).

Díky moc!

Logovanie vsetkych SQL prikazov (aj pre transakciu) (Obecná diskuse)

MIKI — Mon, 09 Jan 2012 11:44:52 +0100

@Milo:

diky, GitHub nepozeram, stahujem len zip z tejto stranky, a dlho som ani nestahoval, netusil som, ze sa to este dako vyvija :)

Nuz, mne osobne ani tak neslo o to, aby som tam mal presny SQL dotaz, ale postacilo by „BEGIN TRANSACTION“ v logu.

Este raz diky, skusim pozriet ten DibiEvent :)

Problém s includovaným připojením k databázi (Řešení potíží)

Milo — Sun, 08 Jan 2012 20:28:14 +0100

Zkus namísto require použít require_once.

Logovanie vsetkych SQL prikazov (aj pre transakciu) (Obecná diskuse)

Milo — Sun, 08 Jan 2012 20:25:59 +0100

Pokud chceš nasazovat i následující verze, koukni na aktuální verzi na GitHub. Tam už se DibiProfiler nepoužívá, ale je nahrazen $dibiConnection->onEvent callbacky. Je to v jednom z nejnovějších commitů. Starého chování logování do souboru dosáhneš takto:

$config = array(
        ...
        'profiler' => array(
                'run' => true,
                'file' => 'dibi.log',
        ),
        ...
);

Případně si teď snadno vytvoříš vlastní loger:

function dibiLogger(DibiEvent $event)
{
        ....
}

$db = new DibiConnection($config);
$db->onEvent[] = 'dibiLogger';

A k tomu, proč se neloguje BEGIN, COMMIT… Nevím to jistě, ale asi to bude tím, že ne každý driver začíná/končí transakcí pomocí SQL kódu. Třeba firebird používá ibase_trans().

Problém s includovaným připojením k databázi (Řešení potíží)

taubda — Sat, 07 Jan 2012 20:12:13 +0100

Zdravím,
mám problém s připojením k databázi. Jsem teprve začátečník s DIBI, takže je možné že jsem udělal nějakou chybu v zápisu.Ted již k popisu problému – když mám připojení napsáno v souboru a pak ho pouze includuji. Pokud mám připojení normálně v souboru, jde všechno krásně, ale z jiného souboru ne.

require("dibi/dibi.php");   // V souboru
include "connect.php";


<?php
require("dibi/dibi.php");       //V souboru, connect.php
dibi::connect(array(
            'driver'   => 'mysql',
            'host'     => '127.0.0.1',
            'username' => 'root',
            'password' => '',
            'database' => ''
        ));

Na stránce mi to poté vyhazuje hlášku Fatal error: Cannot redeclare class DibiVariable in D:\PHP\EasyPHP\www\admin\dibi\dibi.php on line 65, což opravdu nechápu.
Děkuji všem za rady

Taubda

Logovanie vsetkych SQL prikazov (aj pre transakciu) (Obecná diskuse)

MIKI — Sat, 07 Jan 2012 14:24:06 +0100

Zdravim,

Po asi polhodine som nasiel problem, a chcem sa spytat, preco je DibiProfiler takto (podla mojho nazoru) zle rieseny.

Je mozne nastavit Filter pre DibiProfiler, defaultne to je

<?php
        /** @var int */
        private $filter = self::ALL;
?>

Ako som pozeral, tak to znamena logovanie VSETKYCH typov dotazov.
ALE!

metoda DibiProfiler::after() sa sprava inak

<?php
                // ocakavane spravanie, vyfiltruje co nechceme
                if (($event & $this->filter) === 0) return;

                // nesledoval som, o co presne ide, ale ocakavam, ze nieco specialne pre QUERY, OK
                if ($event & self::QUERY) {
                        ...

                        // taktiez vcelku ocakavana podmienka
                        if ($this->file) {
                                $this->writeFile(
                                ...
                        }
                } // ~ tu je koniec podmienky (if QUERY)
        }// ~ tu je koniec funkcie after()
?>

Preco sa podmienka if(file) nachadza tak skoro? Ak sa pre QUERY zapisuje nieco specialne, tak OK, potom ale otazka znie, preco sa nezapisuju ostatne prikazy (BEGIN, COMMIT, ROLLBACK) ? Ak si to mozem vyfiltrovat (napr. nastavit defaultny filter na QUERY), nevidim dovod preco nelogovat aj ostatne prikazy.

Ja si to opravim pre svoju verziu dibi, co mi ale nedovoluje pouzivat najnovsie verzie, prip. mini verzie.

Podla mojho nazoru, by bolo vhodne toto opravit, alebo mi vysvetlite aktualny stav :)

Dumpnutí celé databáze (záloha) (Obecná diskuse)

stanley89 — Thu, 22 Dec 2011 20:36:57 +0100

http://odvarko.cz/…dump-pro-php

Dumpnutí celé databáze (záloha) (Obecná diskuse)

bucrijos — Thu, 22 Dec 2011 16:59:26 +0100

Ok, díky.

Já totiž chci využít DUMP DB přímo v mém miniCMS, tak ptoto jsem se ptal. ;)

Dumpnutí celé databáze (záloha) (Obecná diskuse)

paranoiq — Tue, 20 Dec 2011 18:05:49 +0100

od toho jsou nástroje jako třeba mysqldump

Pridani STRAIGHT_JOIN stejneho jako leftjoin (Diskuse o vývoji Dibi)

Ani — Sun, 18 Dec 2011 23:15:03 +0100

Dík, nakonec jsem na to taky přišel, čekal jsem v tom fluentu nějakou vědu a ono je to napsaný takhle chytře a jednoduše :)

Pridani STRAIGHT_JOIN stejneho jako leftjoin (Diskuse o vývoji Dibi)

Milo — Sun, 18 Dec 2011 23:08:07 +0100

Můžeš si to přidat sám po includu dibi knihoven:

DibiFluent::$clauseSwitches['STRAIGHT_JOIN'] = 'FROM';

DibiFluent, LIMIT, OFFSET a fetch() (Řešení potíží)

Milo — Sun, 18 Dec 2011 23:01:07 +0100

kopec napsal(a):

Ahoj, potřebuji získat jeden konkrétní řádek v pořadí, ale vrací mi to chybu kvůli nesprávnému pořadí LIMIT a OFFSET:
<?php
$query->limit(1)->offset($offset)->fetch();
//...LIMIT 1 OFFSET [cislo] LIMIT 1

$query->offset($offset)->fetch();
//...OFFSET [cislo] LIMIT 1
?>

Jakou verzi používáš? Mně se pořadí vždy nastaví správne LIMIT x OFFSET y. Ve verzi 1.5rc i 1.2.

Napadá mě
<?php
$query->limit(1)->offset($offset)->fetchAll();
return $query[0];
?>
ale to není moc elegantní.

To je bug. Asi ho ani nelze obejít bez editace zdrojáků. Můžeš si DibiFluent::fetch() upravit takto:

public function fetch()
{
        if ($this->command === 'SELECT') {
                $fluent = clone $this;
                return $this->connection->query($fluent->limit(1)->_export())->fetch();
        } else {
                return $this->connection->query($this->_export())->fetch();
        }
}

S tím možná souvisí i další věc, a to sice, že se LIMIT nepřepisuje, ale přidává
<?php
$query->limit(1)->limit(2);
?>
vrací celkem nelogicky …LIMIT 1 LIMIT 2 místo očekávaného …LIMIT 2.

Opět… jakou verzi máš? Mě funguje přepisování.

Pridani STRAIGHT_JOIN stejneho jako leftjoin (Diskuse o vývoji Dibi)

Ani — Sun, 18 Dec 2011 20:15:13 +0100

Ahoj, potreboval bych zapsat STRAIGHT_JOIN do fluentu, tak by se choval jako statni joiny (tj, kdyz se zapise za where aby se zaradil pred nej). Bylo by mozne tuto funkcionalitu do dibi pridat?

DibiFluent, LIMIT, OFFSET a fetch() (Řešení potíží)

kopec — Sun, 18 Dec 2011 13:55:35 +0100

Ahoj, potřebuji získat jeden konkrétní řádek v pořadí, ale vrací mi to chybu kvůli nesprávnému pořadí LIMIT a OFFSET:

<?php
$query->limit(1)->offset($offset)->fetch();
//...LIMIT 1 OFFSET [cislo] LIMIT 1

$query->offset($offset)->fetch();
//...OFFSET [cislo] LIMIT 1
?>

Napadá mě

<?php
$query->limit(1)->offset($offset)->fetchAll();
return $query[0];
?>

ale to není moc elegantní.

S tím možná souvisí i další věc, a to sice, že se LIMIT nepřepisuje, ale přidává

<?php
$query->limit(1)->limit(2);
?>

vrací celkem nelogicky …LIMIT 1 LIMIT 2 místo očekávaného …LIMIT 2.

Dumpnutí celé databáze (záloha) (Obecná diskuse)

Milo — Sat, 17 Dec 2011 20:57:35 +0100

Jednoduše ne.

Dumpnutí celé databáze (záloha) (Obecná diskuse)

bucrijos — Sat, 17 Dec 2011 17:05:28 +0100

Je možné v dibi (případně za pomoci Nette) jednoduše dumpnout (vytvořit zálohu) celou databázi?

DibiConnection – proč se při překladu dotazu pojit k databázi? (Řešení potíží)

Milo — Wed, 14 Dec 2011 21:50:41 +0100

Myslím, že jedním z důvodů je mysql_real_escape_string() v MySQL driveru.

DibiConnection – proč se při překladu dotazu pojit k databázi? (Řešení potíží)

maarlin — Wed, 14 Dec 2011 18:07:08 +0100

Proč se dibi samovolně při překladu dotazu – např. takto:

$query = (string) $this->connection->select('*')->from('articles');

pokouší připojit k databázi?

To snad z principu DB layeru není v tento moment potřeba, nebo se mýlím? Překladem na string bych očekával, že dostanu prostě syntakticky přeložený dotaz a k jeho sestavení imho opravdu není potřeba spojení do databáze.

Jde mi konkrétně o tato dvě místa (dvě metody, které volá __toString()) v DibiConnection:

/**
 * Returns the driver and connects to a database in lazy mode.
 * @return IDibiDriver
 */
final public function getDriver()
{
        $this->connected || $this->connect(); // Here
        return $this->driver;
}

/**
 * Generates SQL query.
 * @param  array
 * @return string
 */
private function translateArgs($args)
{
        $this->connected || $this->connect(); // Here
        return $this->translator->translate($args);
}

Logování SQL dotazů do FireLoggeru (Tipy, triky, návody)

Milo — Tue, 13 Dec 2011 20:43:21 +0100

Při vývoji s oblibou používám Firebug a FireLogger a to v té nejjednodušší podobě flog($var). Také se mi líbí jak dibi loguje do Firebug konzole. Je to ale trochu na hlavu, stále překlikávat mezi Firebug konzolí a FireLoggerem. Stačí však vlastní malý DibiProfiler, který do FireLoggeru loguje. Navíc podle délky trvání dotazu použije příslušný log level.

<?php

/**
 * Odesílá SQL dotazy do FireLoggeru.
 * @todo  Implementovat FireLogger protokol namísto používání třídy FireLogger.
 *
 * Podle doby trvání SQL dotazu použije příslušný log level.
 *     >= 100ms - critical
 *     >=  15ms - warning
 *     <   15ms - info
 */
class MyDibiProfiler extends DibiProfiler
{
        protected static $flogCnt = 1;

        public function after( $ticket, $res = NULL )
        {
                if (!isset(self::$tickets[$ticket])) {
                        throw new InvalidArgumentException('Bad ticket number.');
                }

                list($connection, $event, $sql, $time) = self::$tickets[$ticket];

                parent::after($ticket, $res);

                if (($event & self::QUERY) && (count(self::$fireTable) < self::$maxQueries) && (class_exists('FireLogger', false) && $this->useFirebug)) {
                        for ($i = self::$flogCnt++; $i < count(self::$fireTable); $i++) {
                                $row = & self::$fireTable[$i];

                                if ($row[0] >= 100) {
                                        $lvl = 'critical';

                                } elseif ($row[0] >= 15) {
                                        $lvl = 'warning';

                                } else {
                                        $lvl = 'info';
                                }

                                FireLogger::$default->log($lvl, $row[1]);
                                FireLogger::$default->log($lvl, "-- Time:$row[0]   Rows:$row[2]   Connection:$row[3]");
                        }
                }
        }
}

Jiný způsob getInsertId() a získávání defaulně vložených hodnot u PostgreSQL (Tipy, triky, návody)

Semik — Wed, 07 Dec 2011 23:17:50 +0100

Pak ještě je možnost tu vloženou hodnotu získat ze sekvence pokud jde jen o ID, ale musí to být zase v transakci aby to bylo sekvenčně.