dibi fórum :

Feature request – nastavitelny DibiProfiler file pomocou konfigu (Obecná diskuse)

westrem — Sat, 04 Sep 2010 14:50:50 +0200

Ahoj, vopred sa ospravedlnujem ak som to umiestnil do blbej kategorie, ale nic typu „Feature requests“ som tu nenasiel.

Takze o co sa jedna? Dost ma prekvapilo, ze DibiProfiler->file sa neda nastavit pomocou konfiguracneho suboru, resp. nereaguje na to, ked v poli $config dostane aj direktivu file.

Stacilo by podla mna pridat do jeho konstruktoru nieco taketo:

if (isset($config['file'])) {
    if (class_exists('Environment')) {
        $this->file = Environment::expand($config['file']);
    }
    else {
        $this->file = $config['file'];
    }
}

Co vy na to?

helper funkce pro všechny proměnné pro UPDATE nebo INSERT. (Obecná diskuse)

Milo — Thu, 02 Sep 2010 08:58:22 +0200

Nelze použít třeba…?

dibi::query( "UPDATE tabulka SET", array_map( 'String::normalize', $zmena ));

helper funkce pro všechny proměnné pro UPDATE nebo INSERT. (Obecná diskuse)

knyttr — Thu, 02 Sep 2010 03:18:59 +0200

Ahoj,

je nějak možné řící dibi, aby pro všechny zadané proměnné dotazu INSERT nebo UPDATE aplikovalo nějakou funkci – jako například odstranění bílých znaků z konců řádků?

např.:

<?php
        $zmena = array( 'jmeno' => ' jmeno    ', 'adresa' => 'adresa   ', 'mesto' => 'mesto   ' );
        dibi::query( "UPDATE tabulka SET", $zmena, "String::normalize" );
?>

Díky.

Chyba orderBy() po Dibi upgrade (Řešení potíží)

David Grudl — Sat, 28 Aug 2010 03:18:09 +0200

DibiResult nikdy metodu orderBy nemělo. To budeš mít chybu někde jinde…

Chyba orderBy() po Dibi upgrade (Řešení potíží)

weckho — Fri, 27 Aug 2010 18:21:07 +0200

Ahoj,

po upgradu Dibi, společně s Nette, verze 0.9.5 stable ze dne 1. 7. 2010 (stáhl jsem to společně v jednom) mi začala aplikace hlásit u tohoto dotazu:

return $this->db->query("SELECT u.id, u.nick, u.avatar, c.date, c.text FROM users u LEFT JOIN users_comments c
                            ON  u.id=c.autor WHERE c.id_users = '$id'")->orderBy('c.id', 'DESC');

Následující chybu: MemberAccessException Call to undefined method DibiResult::orderBy().

Ona skončila podpora metody orderBy(), nebo v čem je chyba? Děkuji moc za pomoc.

Like vyhledavani z promenne s % (Obecná diskuse)

westrem — Fri, 27 Aug 2010 01:52:30 +0200

Milo napsal:

Hezke! A moc .. musel som to sice az dvakrat precitat ten post aby som si uvedomil, ze na value sa referencujes cez %v ale je v tom pekna logika ..

Like vyhledavani z promenne s % (Obecná diskuse)

David Grudl — Fri, 27 Aug 2010 01:07:47 +0200

Implementováno všude s výjimkou PostgreSQL a Oracle (nemám k dispozici).

Like vyhledavani z promenne s % (Obecná diskuse)

Milo — Thu, 26 Aug 2010 15:04:33 +0200

Nepochopil som ako by sa to malo spravat, skus ozrejmit :)

<?php
  ( "SELECT * FROM table WHERE col LIKE %like", $value ); // nelze, není jasné jaké % ve $value se má escapovat

  // Obecne
  ( "SELECT * FROM table WHERE col LIKE %like", array( 'format', $value1 [, $value2] ));

  // Konkretne
  $search = "Ferda";
  ( "SELECT * FROM table WHERE col LIKE %like", array( '%%v', $search ));

  // Vysledne SQL
  $sql = "SELECT * FROM table WHERE col LIKE '%Ferda'";


  ( "SELECT * FROM table WHERE col LIKE %like", array( '%%v%', "100%" ));
  $sql = "SELECT * FROM table WHERE col LIKE '%100\%%'";


  ( "SELECT * FROM table WHERE col LIKE %like", array( '%%v%%v', "Jedna", "Dve" ));
  $sql = "SELECT * FROM table WHERE col LIKE '%Jedna%Dve'";


  // Hardcore (escapovat i podtrzitko)
  ( "SELECT * FROM table WHERE col LIKE %like", array( '_%v%%v_', "Jedna%", "Dve__" ));
  $sql = "SELECT * FROM table WHERE col LIKE '_Jedna\%%Dve\_\__'";

?>

Formát je na zvážení…

EDIT: Vlastne by se dalo ve formatu pouzivat klasika %s, %d…

Like vyhledavani z promenne s % (Obecná diskuse)

westrem — Thu, 26 Aug 2010 14:49:29 +0200

Dr.Diesel napsal: Jeste by mozna sla jedna modifikace %s :)))

To uz asi skorej nie, tie modifikatory co si napisal mi pridu uz narocne na zapamatovanie a zbytocne komplikuju prehladny zapis pomocou %like

A border imho v modifikatorech neni Davide, proc myslis?

Ked si pozries API k dibi konkretne uz sekciu, kde sa parsuje cela query do native podoby tak uvidis par TODOciek o presmiestneni a zmene vyznamu u par modifikatorov, asi toto mal David na mysli

Milo napsal: Co něco jako:

Nepochopil som ako by sa to malo spravat, skus ozrejmit :)

Like vyhledavani z promenne s % (Obecná diskuse)

David Grudl — Thu, 26 Aug 2010 14:47:10 +0200

maTidla dobrá, beru :-)

Like vyhledavani z promenne s % (Obecná diskuse)

Milo — Thu, 26 Aug 2010 13:12:05 +0200

Co něco jako:

<?php
dibi::query( "SELECT * FROM table WHERE col LIKE %like ", array( '%%val1%%val2%', $val1, $val2 ), " AND ... " );
?>

Navíc se v LIKE dá použít ještě podtržítko jako zástupný znak.

Like vyhledavani z promenne s % (Obecná diskuse)

Dr.Diesel — Thu, 26 Aug 2010 12:41:29 +0200

westrem napsal(a):

Ten %like operator sa mi paci .. co takto pouzit tildu namiesto hviezdicky na urcenie smeru prehliadania? Tzn:

%~like

%like~

%~like~

Alebo je problem aj s tildou?

Trochu problem by mohl byt, ze nekteri treba zacinajici vyvojari by tildu nemuseli na klavesnici najit :)) Ale jinak za me dobry :) .

Navrhoval bych jeste pro neco pouzit pouzit samotne %like – z meho pohledu pro pravostranne rozsireni, ktere je imho nejcastejsi (ale muze to byt jen muj pripad), tj.

%like = %like~ = slovo%

Jeste by mozna sla jedna modifikace %s :)))

%sP = %like~
%Ps = %~like
%PsP = %~like~
+ %sPN, %PsN, %PsPN

A border imho v modifikatorech neni Davide, proc myslis? :-D

Like vyhledavani z promenne s % (Obecná diskuse)

westrem — Thu, 26 Aug 2010 11:50:24 +0200

Ten %like operator sa mi paci .. co takto pouzit tildu namiesto hviezdicky na urcenie smeru prehliadania? Tzn:

%~like
%like~
%~like~

Alebo je problem aj s tildou?

Like vyhledavani z promenne s % (Obecná diskuse)

David Grudl — Wed, 25 Aug 2010 19:55:18 +0200

Tohle jsem chtěl přidat už dávno, ale nikdy jsem nepřišel na to, jakou zvolit syntax. Na nic univerzálního jsem nepřišel, ale faktem je, že v drtivé většině případů skutečně stačí hledat 'slovo%','%slovo','%slovo%' a na to by se modifikátory daly udělat.

Nicméně v modifikátorech začíná být border a %sr, %sl, %sb se mi moc nelíbí. Možná nějaké kombinace s %like? Nebo něco jako %*like, %like*, %*like*. Ačkoliv hvězdička jako součást modifikátoru není dobrý nápad, mohlo by to porušit zpětnou kompatibilitu, pokud někdo používá třeba %d*10.

Máte nápad?

DibiRow nededi od DibiObject (Obecná diskuse)

David Grudl — Wed, 25 Aug 2010 16:21:25 +0200

Třídy Object byly vždy prapředky těch tříd, u kterých to mělo smysl. Nikdy třeba nebyly prapředky statických tříd (jako je například Debug) nebo „anonymních tříd“. Skutečně mě nenapadá, k čemu by bylo dědictví Object třídě DibiRow ku prospěchu. Tím neříkám, že by nebylo, jen mě to nenapadá a tak se ptám.

DibiRow nededi od DibiObject (Obecná diskuse)

paranoiq — Wed, 25 Aug 2010 12:47:31 +0200

som myslel, ze sa jedna o bug, kedze DibiRow uz nededi od ArrayObjectu a ze sa zabudlo nahradit dedenim od DibiObjectu

také jsem měl ten dojem

DibiRow nededi od DibiObject (Obecná diskuse)

westrem — Wed, 25 Aug 2010 12:01:27 +0200

Od toho se upustilo už před dávnem, spousta tříd v nette nedění od Nette\Object.

Tak toto rozhodnutie mi asi nejak uniklo, ako som si cital API od Nette 0.9.5 prislo mi, ze takmer vsetko dedilo od Objectu.

A je takový problém implementovat si to sám? ;] Tedy udělat si třídu:

Nie je, ja mam na entity napisanu celkom peknu, silnu triedu, ktora sklbuje vsetky vyhody DibiRow, Objectu plus par drobnosti naviac.

Ale jinak není žádný důvod aby entity dědily od DibiRow.

No je ci neni. Ak nededis od DibiRow a nemas naimplementovane veci na ArrayAccess, IteratorAggregate a Countable tak prichadzas o array-like syntax a niekomu to mozno nemusi dojst.

Celkovo som tento „problem“ postol pretoze:

som myslel, ze sa jedna o bug, kedze DibiRow uz nededi od ArrayObjectu a ze sa zabudlo nahradit dedenim od DibiObjectu
by sa to mohlo napr. zaciatocnikom hodit ak by dedilo od DibiObjectu

DibiRow nededi od DibiObject (Obecná diskuse)

PetrP — Wed, 25 Aug 2010 04:21:41 +0200

westrem napsal(a):

Naviac som mal pocit ze triedy Object, resp. DibiObject maju tendenciu byt prapredkami akehokolvek objektu, preco teda zrazu tato vynimka?

Od toho se upustilo už před dávnem, spousta tříd v nette nedění od Nette\Object.

Je taky problem zaimplementovat to dedenie?

A je takový problém implementovat si to sám? ;] Tedy udělat si třídu:

abstract class BaseEntity extends DibiRow
{
        ...

        public function __set($name, $value)
        {
                return ObjectMixin::set($this, $name, $value);
        }

        ...

}

Ale jinak není žádný důvod aby entity dědily od DibiRow.

fetchAssoc a NULL vrati cudne pole (Řešení potíží)

mino — Wed, 25 Aug 2010 01:11:15 +0200

mam

<?php
fetchAssoc('id->id_data=name_data')
?>

ked vsak v niektorom riadku je id_data aj name_data NULL vrati mi to v kluci id_data taketo pole

<?php
      "id_data" => array(1) {
         "" => NULL
      }
?>

nebolo by lepsie keby to vratilo prazdne pole pripadne NULL?

Jak na efektivní práci s pamětí PHP při získávání výsledků z DB (Obecná diskuse)

David Grudl — Wed, 25 Aug 2010 01:02:25 +0200

Ano, fetchAll() zachází s pamětí zcela nejhůř, protože celou strukturu drží v poli objektů. Pokud je to možné, je lepší se mu vyhnout. Také daleko lépe s pamětí zachází unbuffered přístup, který se dá na některých ovladačích zapnout (MySQL, MySQLi, SQLite), na některých je zapnutý defaultně (PDO, SQLite3).

DibiRow nededi od DibiObject (Obecná diskuse)

westrem — Wed, 25 Aug 2010 00:53:00 +0200

David Grudl napsal(a):

K čemu by dědění od DibiObject bylo dobré?

Ako spominam v prvom prispevku, pre metodu setRowClass sa „odporuca“ nastavovat triedu, ktora je potomok DibiRow. Ak chceme dodrziavat danu konvenciu a mame vytvorenu urcitu triedu, ktora reprezentuje nasu entitu v databaze tak tym, ze DibiRow nededi od DibiObject prichadzame v nasej entitnej triede o vsetky jeho vyhody.

Naviac som mal pocit ze triedy Object, resp. DibiObject maju tendenciu byt prapredkami akehokolvek objektu, preco teda zrazu tato vynimka?

Je taky problem zaimplementovat to dedenie?

DibiRow nededi od DibiObject (Obecná diskuse)

David Grudl — Wed, 25 Aug 2010 00:33:30 +0200

K čemu by dědění od DibiObject bylo dobré?

fetchAssoc a nerozpoznanie property (Řešení potíží)

westrem — Wed, 25 Aug 2010 00:12:37 +0200

Zdravim, dnes som narazil na jednu zvlastnost ked mi Dibi zacalo hadzat vynimku (API)

throw new InvalidArgumentException("Unknown column '$as' in associative descriptor.");

Dovodom bol fakt, ze som sa pokusil o nasledovne:

$r->fetchAssoc('id');

Kde vsak $row mal danu property id ako private a pristupit sa k nej dalo pomocou getteru getId pripadne vdaka magickej metode __get u DibiObject-u.

Tymto sposobom vsak fetchAssoc zlyha na kontrole ci existuje dana property, pretoze property_exists nedokaze skontrolovat existenciu property pokial je pristupna aj inak ako len napriamo. Samotnemu vykonaniu kodu to vsak nevadi, pretoze pri neskorsom volani napr. $row->$as sa pristupi vdaka __get metode priamo k pozadovanej private property.

Navrhujem preto zmenit podmienku na riadku 315 z

if ($as !== '[]' && $as !== '=' && $as !== '->' && $as !== '|' && !property_exists($row, $as)) {
...
}

if ($as !== '[]' && $as !== '=' && $as !== '->' && $as !== '|' && !property_exists($row, $as) && !method_exists($row, 'get'.ucfirst($as))) {
...
}

To by kontrolovalo existenciu gettera na danu property a mohlo by sa to vyuzit v nasledovnom kode. Pripadne ak existuje efektivnejsie riesenie tohto „problemu“ tak sem s nim, vyssie uvedena podmienka je len moj „hot fix“, ktory ako sami isto viete spolieha v pripade neexistencie priamo dostupnej property na pretazovanie pomocou __get.

DibiDataSource, DiBiFluent a klonování (Řešení potíží)

semtex.989 — Tue, 24 Aug 2010 17:20:26 +0200

Toto téma zakládám bych ušetřil čas a nervy všem, co hledají řešení jako já. Líbilo se mi DibiDataSource, ale moje požadavky byly:

Skládání dotazu alá DibiFluent, bez převádění metodami toFluent() a toDataSource()
funkční klonování objektu DataSource (Dibi používání při skládání dotazu reference u polí, takže jsem se to snažil vyřešit)
Aby DataSource místo DibiRow vracelo jinou třídu.
Aby tato třída mohla místo sebe vrátit jinou
Je mi známa chyba v DibiDataSource, která způsobí, že pokud se zavolá getResult(), tak už nelze dál modifikovat SQL dotaz.

Má to nevýhodu, že je nutné v DibiFluent upravit atribut clauses z private na protected, ale to dá přežít…

Jinak děkuji Davidovi za perfektní práci odvedenou na Dibi ;-)

Výsledkem je třída DataSource:

<?php
final class DataSource extends DibiFluent implements IDataSource{

      private $rowClass = null;


      public function __construct(DibiConnection $connection, object $rowClass = null){
            parent::__construct($connection);
            $this->setRowClass($rowClass);
      }

      public function setRowClass(object $rowClass = null){
            $this->rowClass = $rowClass;
            return $this;
      }

      public function getRowClass(){
            return $this->rowClass;
      }


      public function getResult(){
            $rows = $this->fetchAll();
            if(count($rows) < 1){
                  return null;
            }
            if($this->rowClass !== null){
                  $return = array();
                  foreach($rows  as $row){
                        $class = clone $this->rowClass;
                        $return[] = $class->setData($row); // zde je možnost, že třída vrátí místo sebe jinou třídu
                  }
                  if(count($return) == 1){
                        $return = $return[0];
                  }
                  return $return;
            }
            return $rows;
      }

      public function getIterator(){
            return new ArrayIterator($this->getResult());
      }

      public function __clone(){
            $this->clauses = unserialize(serialize($this->clauses)); // HACK: clones clauses!
      }

}
?>

Like vyhledavani z promenne s % (Obecná diskuse)

Dr.Diesel — Tue, 24 Aug 2010 12:29:10 +0200

Ahoj vsem, co se tyce like, nejsou pres modifikator %s escapovana procenta, mozna by stalo za zvazeni, zda v tomto neco neudelat:

//uzivatel zadal do inputu '%slovo%'
$word = '%slovo%';

//vyhledavani pravostranneho rozsireni, pri spolehnuti na dibi se ale % dostane az do LIKE
dibi::test('select * from [table] where [col] like %s',$word.'%');

//zadavani tohoto je imho dost "nenette/nedibi" :))
$word = str_replace('%','\%',$word);
//navic to funguje pomerne nahodou, protoze dibi escapuje to lomitko, mysql to ale presto sezere jako escape toho procenta
dibi::test('select * from [table] where [col] like %s',$word.'%');

Vysledkem je pak problematicke vyhledavani s oboustrannym rozsirenim, ktere je zasadne pomale a nezadouci, pokud vyvojar sam nestanovi jeho pouziti v kodu.

Nebo jsem neco prehlidl? ;-)

Mozna by staly za zvazeni modifikatory %sr, %sl, %sb (? +N), ktere by sestavovaly 'slovo%','%slovo','%slovo%' a uvnitr vyrazu procenta escapovaly.

SQL translate error při použití escapovaných apostrofů (Řešení potíží)

LeonardoCA — Mon, 23 Aug 2010 14:46:56 +0200

Tak % to nakonec nebylo a funguje to takto:

dibi::query("SELECT DATE_FORMAT(NOW(),\"%b '%y\") from dual");

4474 záznamů ⇒ fetchAll ⇒ 500 Internal server error (Řešení potíží)

PetrP — Mon, 23 Aug 2010 10:35:52 +0200

Pomoci fetch myslel treba takto:

return dibi::query('SELECT * FROM [:net:log]');
...
foreach ($foo as $row) ...

SQL translate error při použití escapovaných apostrofů (Řešení potíží)

Ondřej Mirtes — Sun, 22 Aug 2010 23:22:31 +0200

Problém není v tom escapovaném řetězci, ale v těch % parametrech. Zkus zdvojit ty procenta.

DibiRow nededi od DibiObject (Obecná diskuse)

westrem — Sat, 21 Aug 2010 16:45:18 +0200

paranoiq napsal(a):

aha! koukal jsem na obstarožní verzi z jara. strč to do issues na githubu

Okej pridane do issues, aj ked dufam, ze dobre, s GitHubom som este nepracoval O:-)

SQL translate error při použití escapovaných apostrofů (Řešení potíží)

LeonardoCA — Fri, 20 Aug 2010 16:46:04 +0200

potřebuji použít v sql následující výraz '%b \'%y'

např.:

dibi::query("SELECT DATE_FORMAT(NOW(),'%b \'%y') from dual");

a dibi vyhodí chybu SQL translate error, přitom samotný SQL dotaz funguje správně, jak toto ošetřit?

BUG v substitucích, asi někde probíhá cache (Řešení potíží)

Blizzy — Thu, 19 Aug 2010 16:06:39 +0200

Následující kód:

$connection = dibi::connect(Environment::getConfig('database'));

dibi::addSubst('id', 'A.id');
dump($connection->translate('[:id:]'));
dibi::removeSubst('id');

dibi::addSubst('id', 'B.id');
dump($connection->translate('[:id:]'));

vypíše:

"`A`.`id`" (8)
"`A`.`id`" (8)

očekávaný výstup je:

"`A`.`id`" (8)
"`B`.`id`" (8)

Verze: 1.3-dev 8dc164d released on 2010-08-05

Snad tohle pomůže: U toho translate dělají problém hranaté závorky, samotné ':id:' se překládá správně (tedy substituuje se za A i za B), problém je s identifikátorem, tj. '[:id:]'.

Bude to asi tím, že se cachují identifikátory jako třída DibiLazyStorage a identifikátor se substitucí tam přetrvá i když se substituce změní.

EDIT: Issue na githubu: http://github.com/…/dibi/issues#…

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

mcmatak — Wed, 18 Aug 2010 20:27:20 +0200

takze jsem aktualizoval na dibi 1.3 kde jak se zda je to vyreseno, puvodne jsem mel verzi 1.1

v kazdem pripade dibi 1.3 je rozdilna v mnoha vecech, uz jen treba absence inTransaction, coz se musi patchnout, ppredstava ze predavam vsem funkcim jeslti jsem zrovna v transakci by mi dalo asi tak tyden prepsat celou aplikaci, a app by se o dost zeslozitila,

pokud odpovedi maji byt savepointy nedokazu si predstavit napr. orm, ktere v cyklu uklada objekty a tento cyklus je v transakci vymyslet unikatni savepoint pro kazdy objekt … no nevim … vykon app rapidne dolu, prehlednost rapidne k zemi, slozitost rapidne nahoru, no ale jina pohadka, to je postesk snad jen…

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

paranoiq — Wed, 18 Aug 2010 20:06:45 +0200

nevidím jak z toho ven bez úpravy DF. tak jak je to napsáno by sis nepomohl ani kdyby kursor byl protected :[

chtělo by to, aby kursor byl index do pole clauses a nikoliv reference na jeho prvek UPDATE: … což pochopitelně nepůjde, clauses je asi strom, že? :[

(snad jsem to pochopil správně)

DibiRow nededi od DibiObject (Obecná diskuse)

paranoiq — Wed, 18 Aug 2010 19:48:59 +0200

aha! koukal jsem na obstarožní verzi z jara. strč to do issues na githubu

DibiRow nededi od DibiObject (Obecná diskuse)

westrem — Wed, 18 Aug 2010 19:21:03 +0200

paranoiq napsal(a):

protože dědí do PHPčkového ArrayObject

Ja tam zadne extends nevidim: DibiRow Source File

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

mcmatak — Wed, 18 Aug 2010 17:48:10 +0200

<?php

tak nikde jsem zadne reference nenasel

prepsal jsem si metodu __call zhruba takhle

        public function __call($clause, $args)
        {
                switch($clause) {
                        // callback na # je docela nebezpecny, napr. regulary mohou obsahovat # atd. tedy pokud nechci aby se prekladal sign # tak pouziju rselect
                        case 'rselect':
                                        if ($args[0] === false) {
                                                $this->selects = array();
                                        }
                                        return parent::__call('select', $args);

?>

a při volání parent::__call dochází k tomu že zapisuje k původnímu objektu a ne k tomu clonovanému**

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

mcmatak — Wed, 18 Aug 2010 17:34:21 +0200

http://php.vrana.cz/…-objektu.php

takže jestli správně rozumím musím si kopie vytvářet ručně, a musím tedy opět zasáhnout do dibifluent protože jsou ty reference private

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

mcmatak — Wed, 18 Aug 2010 17:31:06 +0200

asi sem byl moc rychlej, uz to zase nefunguje sakra

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

mcmatak — Wed, 18 Aug 2010 17:30:09 +0200

samotnou referenci obsahuje dibifluent, snad z nastíněného řešení které jsem doplnil do příspěvku, pochopíš v čem je problém, třeba to jde řešit jinak než zásahem do dibifluent?

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

paranoiq — Wed, 18 Aug 2010 17:25:33 +0200

nejspíš za to může mělká kopie. obsahuje tvůj potomek nějaké jiné objekty nebo reference? ty se při klonování nekopírují

použij __clone()

DibiRow nededi od DibiObject (Obecná diskuse)

paranoiq — Wed, 18 Aug 2010 17:07:47 +0200

protože dědí do PHPčkového ArrayObject

Klon dibifluentu mi změní původní dibifluent při převodu na string? (Řešení potíží)

mcmatak — Wed, 18 Aug 2010 16:05:22 +0200

mam potomka DibiFluent

echo '<div style="float:left;width:500px">';
dump($this);
echo '</div>';

$c = clone $this;

$c->_export();

//              $q = (string)$c;

echo '<div style="float:left;width:500px">';
dump($this);
echo '</div>';

jak je možné že mi klon změní původní dibifluent?

tak už vím kde je problém, nevím jeslti vina php, nebo dibi, ale cursor odkazuje referencí na clauses, jenomže po klonování tato reference nezmizí, a při úpravě nového naklonovaného objektu se díky cursoru upravuje ten původní

řešení:

přidat do dibifluent

private function __clone()
{
$this->cursor = & $this->clauses[‚SELECT‘];
}

DibiRow nededi od DibiObject (Obecná diskuse)

westrem — Wed, 18 Aug 2010 15:27:13 +0200

Ahoj, uz dlhsiu dobu sa cudujem, preco DibiRow implicitne nededi od DibiObject. V pripade DibiResult->setResultClass totiz treba nastavit class, ktora by mala dedit od DibiRow.

Kedze vsak PHP zatial neumoznuje viacnasobne dedenie tak class, ktoru chcem takto nastavit automaticky prichadza o vyhody DibiObjectu.

Je preto nejaky realny dovod, preco prave DibiRow nededi od DibiObjectu?

4474 záznamů ⇒ fetchAll ⇒ 500 Internal server error (Řešení potíží)

paranoiq — Sun, 15 Aug 2010 20:46:44 +0200

fetchAll() musí do paměti zkpírovat všechny záznamy, na což omezená paměť procesu samozřejmě nestačí. vypisuj je postupně pomocí fetch()

4474 záznamů ⇒ fetchAll ⇒ 500 Internal server error (Řešení potíží)

Gaudentius — Sun, 15 Aug 2010 20:01:46 +0200

Ahoj vypisuji si log, kde mám 4474 záznamů:

return dibi::fetchAll('SELECT * FROM [:net:log]');

ale vše skončí bílou stránkou, ani laděnka nevyběhne a ve firebugu vyskočí hláška „NetworkError: 500 Internal Server Error“ – podle mě to bude problém optimalizace, protože, když mám v tabulce 10 záznamů, tak vše funguje jak má.

tbl:

SET FOREIGN_KEY_CHECKS=0;
-- ----------------------------
-- Table structure for `net_log`
-- ----------------------------
DROP TABLE IF EXISTS `net_log`;
CREATE TABLE `net_log` (
  `log_id` int(11) NOT NULL AUTO_INCREMENT,
  `log_name` varchar(255) DEFAULT NULL,
  `log_description` mediumtext,
  `log_date` date DEFAULT NULL,
  `log_time` time DEFAULT NULL,
  `log_timestamp` int(11) DEFAULT NULL,
  `id_admin` int(11) DEFAULT NULL,
  `log_presenter` varchar(255) DEFAULT NULL,
  `log_action` varchar(255) DEFAULT NULL,
  `log_params` mediumtext,
  `log_status_code` int(11) DEFAULT NULL,
  `log_ip` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`log_id`),
  KEY `log_date` (`log_date`),
  KEY `log_presenter` (`log_presenter`),
  KEY `log_action` (`log_action`),
  FULLTEXT KEY `log_name` (`log_name`),
  FULLTEXT KEY `log_description` (`log_description`)
) ENGINE=MyISAM AUTO_INCREMENT=19949 DEFAULT CHARSET=utf8;

v čem by mohla být chybka?

Sjednocení pořadí parametrů fetchAll a applyLimit (Obecná diskuse)

Bernard Williams — Wed, 11 Aug 2010 22:26:14 +0200

Nazdárek,

docela by mě zajímalo, proč mají metody fetchAll u query a applyLimit u dataSource prohozené pořadí parametrů? Mě se to zdá hodně matoucí nebo je to záměr?

Bernard

NEMOŽNÁ chyba s sql dump file (Řešení potíží)

Pepča — Wed, 11 Aug 2010 16:54:23 +0200

Je možné, že když je soubor kódovaný v UTF8, tudíž obsahuje jistý počáteční znak, který narušuje syntaxi?

NEMOŽNÁ chyba s sql dump file (Řešení potíží)

Pepča — Wed, 11 Aug 2010 14:29:29 +0200

Ahoj, mám fakt nervydrásající problé, a to sice házení sytax erroru, i když tam očividně chyba nejni.

Chyba:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"CREATE TABLE IF NOT EXISTS obsah (id TINYINT NOT NULL PRIMARY KEY ' at line 1

kód prvního příkazu:

CREATE TABLE IF NOT EXISTS obsah (id TINYINT NOT NULL PRIMARY KEY,
            titul VARCHAR(20),
            podtitul VARCHAR(40),
            home TEXT,
            sluzby TEXT,
            galerie TEXT,
            clanky TEXT,
            diskuze TEXT)
            CHARACTER SET utf8

Soubor sql.sql nahrávám úspěšně pomocí dibi::loadFile(); příkazy se pomocí MySQL příkazového řádku provedou korektně, chyba v syntaxi je tudíž naprostá hovadina :0

Používám dibi knihovnu obsaženou v distribuci NetteFramework 1.0 pro PHP5.2

dibi – automaticke escapovanie pri dotazoch ? (Obecná diskuse)

Ondřej Mirtes — Tue, 10 Aug 2010 23:55:27 +0200

Ano, pokud využíváš zápis parametrů pomocí dibi syntaxe (viz quick start), tak dochází všude k automatickému escapování a tudíž 100% odolnosti proti SQL injection.

Jak na efektivní práci s pamětí PHP při získávání výsledků z DB (Obecná diskuse)

Proki — Tue, 10 Aug 2010 11:49:27 +0200

Zdravím, zabývám se nyní optimalizací načítání získávaných dat z databáze do PHP. Jsou možné minimálně dvě možnosti, jak řádky načíst a následně zpracovat (viz zdrojový kód níže). Zajímalo by mě, který z nich je efektivnější, a případně i kdy se vyhazují výjimky v případě, kdy dojde při vykonávání dotazu k chybě.

<?php
$items = dibi::query("SELECT * FROM news");
foreach ($items as $item) {
   // práce se záznamem
}

$items = dibi::query("SELECT * FROM news")->fetchAll();
foreach ($items as $item) {
   // práce se záznamem
}
?>

Při zkoumání zdrojových kódů jsem přišel na následující. Dejme tomu že nemáme zanedbatelné množství vrácených řádků (např. stránkování po 100). Při používání prvního způsobu se vykoná dotaz a následně se postupně získávají jednotlivé řádky z databáze. Nevýhodou je to, že nemůžu najednou pracovat s celou kolekcí záznamů, ale při obyčejných výpisech to vůbec nevadí. Druhý způsob mě přijde jako dosti neefektivní, jelikož všechny řádky jsou nejprve načteny do oblasti paměti v PHP a teprve následně s nimi uživatel nějak pracuje, což může být ve většině případů dosti neefektivní.

Je můj náhled na tuto situaci správný nebo se mýlím?