Nette\Database: refactoring API

Vypada to zajimave az na
Nova moznost dovoluje primou definici joinu

$db->table('book')->where('(user, translator_id).born > ?', ...);

Nebylo by lepsi rovnou pridat metodu join nez toto?

$db->table('book')->join('table2', 'table1.id = table2.table1_id')

Nerozumim, join se v sql dotazu vytvori tak jako tak..

Zrušit bindované parametry je docela odvážné.

Parametrům se přisuzují dvě výhody:

1. bezpečnost – nezpůsobí se jimi SQL injection
2. rychlost – nemusí se kódovat do SQL a poté z něj dekódovat

Bezpečnost nás nemusí zajímat, to zajistí ND vždy. Pokud jde o rychlost, nezaznamenal jsem, že by v případě MySQL bylo bindování rychlejší než prosté skládání SQL. MSSQL nebo Oracle jsem nikdy netestoval, ale ty jsou pro nás spíš okrajové databáze. Mezi důležité patří naopak Postgre, kde se binární data kódují dost ukecaně a z „fyzikální podstaty“ je pak bindování binárních dat rychlejší. Právě kvůli binárním datům mi bindování dává smysl.

Stejně tak nesouhlasím s tím, že by nebindování vylepšilo zobrazování v Debug Baru. Pokud ukládám binární data nebo obyčejný textový článek do DB, fakt nechci v Debug Baru vidět haldy textu, jde mi o smysl SQL dotazu. Současné chování je proto takové, že vše krom dlouhých řetězců dává přímo do SQL, a ty dlouhé bokem do params. Dalo by se to upravit tak, že by se sloupeček params úplně zrušil a do SQL dávalo místo otazníku něco jako "...". Rozhodně jde ale o lepší řešení, než tam třísknout obří kusy textu.

Tady přece nejde o to, jestli ty dáváš do DB binární data nebo ne. Ale že tam nedáváš běžně texty delší než pár znaků je mi ale záhadou – neděláš pro Twitter? ;-)

(Možná je to tím, že po INSERT/UPDATE přesměruješ, takže vnímáš spíš Debug Bar jako zobrazovač SELECTů, kde delší texty fakt nebývají.)

Ivorius napsal(a):

Jestli tomu rozumím, bude možné využít vlastní ActiveRow pro překlady ? Nyní mám poděděné Selection, GroupedSelection kde si vytvářím svůj ActiveRowLang – ale není to zrovna asi ideální řešení.

Tohle je naprosto minoritní „problém“. Jde to řešit mnoha různými způsoby bez přímé podpory v Nette DB. např.:

class ActiveRowTranslator
{
	private $lng;

	function __construct($lng)
	{
		$this->lng = $lng;
	}

	function getTranslatedRow($row, $name)
	{
		return $row->{$name . '_' . $this->lng};
	}
}

$template->registerHelper('artranslate', array(new ActiveRowTranslator('cs'), 'getTranslatedRow'));

Text článku: {$article|artranslate:text}

Jenže majorita je jenom část celku a návrh by měl respektovat celek. Že Debug bar neumí zobrazit dotazy při redirektu není ani tak jeho vlastnost, jako spíš nedostatek.

Imho by bylo super, kdyby se dlouhé stringy vůbec nevypisovaly. Mohly by se vypisovat třeba v titulku nad tím '...'. A implementovat přenášení SQL dotazů pomocí session v panelu až do jejich zobrazení taky není špatný nápad a určitě to bude snadné implementovat :)

Nemas pravdu Davide, respektive ses nechal unest. Tvuj commit sice pridal prepisovani booleanu, ale ta nejvetsi krizovatka, zda bindovat ci preprocesorovat, je uplne nekde jinde.

edit: tak koukam, ze sis ten commit skudlil rok :D
edit2: njn, tak vidim, ze uz si to dopushoval :D

Editoval hrach (17. 9. 2012 19:39)

Odstranil jsem z Debugger baru sloupeček params a zobrazuje se poskládané SQL se zkrácenými řetězci.

Proc delat veci jednoduse, kdyz to jde slozite, ze?:)

Kdyz teda join by evokoval propojovani dat z vice tabulek, proc tu metodu nepojmenovat napr joinHint?

Dale, bude se nejak resit SqlLiteral pro vsechny casti dotazu (napr do order by), toho jsem si tu nejak nevsiml? Takhle si rozsiruju funkcionalitu svyho projektu a najednou potrebuju radit podle subquery (v jednom z nekolika pripadu, kde u zbytku to potreba neni), jenze NDB z tohoho subquery zaclo vytvaret joiny v hlavnim dotazu, cimz drasticky stoupla narocnost onoho dotazu, takze jsem si musel NDB trochu hacknout..

ad DebugBar: Z mého pohledu bude vypisování celého SQL i s vloženými parametry vhodnější. Dost často kopíruju položený dotaz třeba do Admineru a dál si s ním hraju. Hledání, kolikátej parametr kde byl, je trošku otrava. Tzn. díky za úpravu :-)

Nové backjoin API vypadá suprově. Konečně to dává smysl.

Jen dotaz k tomuto:

$db->table('book')->where('(user, translator_id).born > ?', ...);
$db->table('author')->group('author.id', ':(book.translator_id).published > ?', ...);

Opravdu má být v prvním případě použita čárka s mezerou mezi tabulkou a cizím klíčem a v druhém tečka? Není to matoucí?

super ze tu tak tleskate, ale me pdo pernamentne na postgresce rve
LSTATE[08P01]: <<Unknown error>>: 7 ERROR: bind message supplies 0 parameters, but prepared statement „pdo_stmt_00000006“ requires 1

	$rows = self::$connection->table(self::$table)->where('contents.id',
			self::$connection->table(self::$tableref)->select('contents_id')->where('categories_id', $categoryid));

--/

Tady

To bude nějaká blbost, smaž odsud tu funkci fetch a mělo by to být ok.

Asi myslíš PHP. :-)

Updatni si Nette na novější než 5.3.9

Tohle zavani dirou ve stazi :D

Co se týče opuštění PDO\Statement: jsem pro, nejspíš by to mělo jít ruku v ruce s opuštěním PDO (tj. Connection nebude potomek PDO. Problém by mohlo být zavedení vlastní výjimky, teoreticky by se dalo udělat něco jako class_alias('PDOException', 'Nette\Database\Exception').

David:
jsem rad, ze se uz doslu k tomu opousteni. Ze je to spravna cesta vim uz pul roku, ale nejak to tady zapadlo. ;)

• buffered queries:
  • jak pises, aktualni verze PR uklada pri fetchi aktualni radek, pro pozdejsi iteraci. Toto by mohlo byt treba zavisle na MYSQL_ATTR_USE_BUFFERED_QUERY, aby pak v poradku pracoval ten dvojnasobny fetchAll
  • vyjimka: chapu to tak, ze chces odchytavat Nette\Database\Exception, ktera === PDOException. Nechapu ovsem rozil oproti dedeni.
• syntaxe joinu:
  • nevim jak pozorne jsi to cetl, ale to v zavorce ma stejny vyznam, jako pri volani metody ref.; tedy pripojit na tabulku users a joinovat pres books.translator_id = users.id. Nerikam ze jet o uplne intuitivni, ale zachovava to logiku. V pripade DiscoveredReflection je tento pripad zrovna zbytecny, staci translator.id.
  • jsou tu situace, kdy se bez necoho napovedneho neda obejit. tj

    // vybere prekladatele, u kterych byla kniha vydana az ...
    // a tady si neporadime ani s DiscoveredReflection :P
    $db->table('author')->group('author.id', ':(book.translator_id).published > ?', ...);

  • ted me napadl takovy algoritmus, na hledani vazby i pro tento pripad, aby to slo:

    $db->table('author')->group('author.id', ':translator.published > ?', ...);

  • takze jsem celkem naklonen od teto zmeny odstoupit. Navic by tomu jeste moc moc pomohl tento PR od @juzny. https://github.com/…tte/pull/649

PS: vsimnete si, jak texy spatne odradkovava v prvnim zanorem bloku codu.

Nojo, jenze s teckou to vypada, jako by dany sloupec patril tabulce users, ne tabule book. Proto, kdyz neco takoveho pisu, tak pro osvetu pouzivam carku (i ve volani metody, kde to tez funguje i s teckou).

get() je podla mna v pohode (vracia where('id', $id)->fetch())

find() je zbytocny, mozno by bol uzitocnejsi, keby vracal row