Bug report: Rozpoznávání datových typů

EDIT: Následující patch nepoužívejte, díky PHP zaokrouhlování float čísel může dojít k monstrózním chybám

Chyba s ořezáváním integeru se projeví i u modifikátoru %i. Tam to lze obejít použitím %f. (Sic i (float) má omezenou délku.)

$db->test('SELECT %i', 123123123123);
// SELECT -1430928461

$db->test('SELECT %f', 123123123123);
// SELECT 123123123123

Podobná malá berlička při automatické detekci může být:

$db->query('......')
   ->setType('sloupecBigint', dibi::FLOAT)
   ->fetchAll();

Používám následující fix (jen u PostgreSQL ve dvou aplikacích, nevím jak ovlivní jiné DB)

// Původní dibi (libs/DibiDatabaseInfo.php -> detectType()
static $patterns = array(
    'BYTEA|BLOB|BIN' => dibi::BINARY,
    'TEXT|CHAR|BIGINT|LONGLONG' => dibi::TEXT,
    'BYTE|COUNTER|SERIAL|INT|LONG' => dibi::INTEGER,
    'CURRENCY|REAL|MONEY|FLOAT|DOUBLE|DECIMAL|NUMERIC|NUMBER' => dibi::FLOAT,
    '^TIME$' => dibi::TIME,
    'TIME' => dibi::DATETIME, // DATETIME, TIMESTAMP
    'YEAR|DATE' => dibi::DATE,
    'BOOL|BIT' => dibi::BOOL,
);

// Fix
static $patterns = array(
    'BYTEA|BLOB|BIN' => dibi::BINARY,
    'TEXT|CHAR|BIGINT|LONGLONG' => dibi::TEXT,
    'INT8|CURRENCY|REAL|MONEY|FLOAT|DOUBLE|DECIMAL|NUMERIC|NUMBER' => dibi::FLOAT,
    'BYTE|COUNTER|SERIAL|INT|LONG' => dibi::INTEGER,
    '^TIME$' => dibi::TIME,
    'TIME' => dibi::DATETIME, // DATETIME, TIMESTAMP
    'YEAR|DATE' => dibi::DATE,
    'BOOL|BIT' => dibi::BOOL,
);

Jak to ale fixnout? Chápat %i jako integer v podání PHP, nebo jako celé číslo s libovolným počtem cifer? Zavést %si modifikátor „string integer“ a využívat nějakou Math knihovnu?


Každopádně jsem za to, aby se PostgreSQL (INT8) detekoval jako PHP (float).

Editoval Milo (14. 4. 2011 14:39)

Jinak do PHP FLOATu se sice ta velká čísla vejdou, ale musí se počítat s tím, že to je float, tzn. při výpisu kamkoliv to nejde prostě pushnout jako proměnnou, ale třeba skrz

sprintf('%.0f', $bigInt);

nebo

number_format($bigInt, 0, '.', '');

Defaultně se to totiž vypisuje ve tvaru s exponentem, což asi v případě, že to má jít třeba do link makra v šabloně je docela nešikovné…

Jestli opravdu nebude úplně nejlepší to defaultně konvertovat na string.

Editoval maarlin (14. 4. 2011 11:44)

maarlin napsal(a):
Navíc Postgre má datové typy víceúrovňových polí (obvykle název dat. typu začíná _), které dibi taky vůbec neřeší a konvertuje na standardní datové typy…

např. pokud mám pole integerů (_INT4), tak ho převede na standardní PHP int, tedy přesněji řečeno na nulu…

PostgreSQL má všobecně více vychytaných typů. MAC adresy, IP s netmaskou, atd… Ale myslím, že je zbytečné, aby tohle dibi celé pokrývalo.

Mám rozpracovaný koncept registrace vlastních modifikátorů. Výsledkem by měl být transparentní převod databázových typů na PHP typy. Nějak ale nezbývá čas to dotáhnout do konce.

class ipv4DibiModificator implements IDibiModificator
{
    public function isValid( $phpValue )
    {
    ...
    }

    public function matchDbNativeType( $type )
    {
    ...
    }

    public function toPhp( $dbValue ) // Z databáze do PHP
    {
    ...
    }

    public function toSql( $phpValue ) // Z PHP do databáze
    {
    ...
    }
}

dibi::registerModificator('ipv4', new ipv4DibiModificator);

// Userspace
dibi::query('INSERT INTO computers (ip_address, hostname) VALUES( %{ipv4}, %s )', $var, $var);

Tak by se daly pokrýt i pole a luxusně vytvářet i rozšíření pro Dibi.

Editoval Milo (14. 4. 2011 15:34)

Dal jsem na github implementaci, která mi ležela nějakou dobu v šuplíku. Více zde na fóru.

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