Přednáška Nette\Database na poslední sobotě

K tomu „zmizeni“ deti mezi vyberem jejich ID a naslednym vyberem vlastnich dat

Cela problematika konzistence (atomicity) mezi vice dotazy je pomerne slozita a vzdy je nutne posuzovat konkretni priklady – kdyz nekdo namitne, „co kdyz mezitim nekdo knizku uplne smaze“, opacim, ze to se v me aplikaci nestane, protoze nic nemazu. Pokud rekne „co kdyz tu knizku nekdo priradi jinemu autorovi“, reknu, ze (pokud resim problem, ze mam predvybrano jeste ID „stareho“ autora), to uzivatel uvidi proste stejn, jako kdyby kliknul o pulvterinu driv, kdy to tak jeste bylo … atd ;)

Ony totiz existuji i mnohem jednodussi priklady, kdy je „neatomicita“ problem – treba obycejne kombo „nejdriv count, ktere mi urci strankovani, pote vyber daneho vyseku dle limitu“ – co kdyz mezi countem a vyberem dojde ke zmene. To je vec, kterou nelze rozumne resit vubec nijak, krome vynuceni transakce se serializovanou izolaci (pokud to dana db vubec podporuje).

TL;DR

Nekonzistence mezi vice SQL typicky neni problem a krajni pripady (kdy to vubec muze nastat / je to realny problem) si clopvek vzdy musi osetrit sam, bez ohledu na pouzitou DB vrstvu.

Člověk se pořád učí:) Např. to s tou dvojtečkou.. V dokumentaci o tom neni ani zmínka a kvůli tomu jsem doteď takový dotazy řešil nějak ve smyslu drbat se levou rukou za pravym uchem:/

Jinak docela bych do Selection bral metody typu fetchColumn, i možná to fetchAll, nechcete to tam přidat?:)

@marek.dusek: otázky typu „co když mi někdo mezitím…“ řeší už pouhé uzavření operací do transakce. na MySQL je defaultně izolace REPEATABLE READ a ta právě tohle zajišťuje (ale dost zamyká)

paranoiq napsal(a):

@marek.dusek: otázky typu „co když mi někdo mezitím…“ řeší už pouhé uzavření operací do transakce. na MySQL je defaultně izolace REPEATABLE READ a ta právě tohle zajišťuje (ale dost zamyká)

to neni uplne pravda – REPEATABLE zaruci, ze „ti nikdo nic nesmaze ani nezmeni“, ale nezaruci, ze nevyberes neco navic (commitovane inserty se do novych selectu zaradi) – tj. dotaz na COUNT muze vratit 5 zaznamu a vyber LIMIT 0, 100 jich vratit klidne 6 (nerikam, ze to „vadi“, ale ze to neni totez)

jinak diky za vysvetleni, ze v mysql je to default – to je docela zasadni informace a netusil jsem, ze jde takto „proti proudu“ (oracle / mssql / postgre, vsude je default read commited) – asi se predpoklada, ze pokud na mysql pobezi neco vytizeneho, bude tam nekdo kompetentni, koho napadne toto zmenit :-)

Editoval marek.dusek (2. 5. 2012 22:47)

fetch

• u fetchPairs bych nechal v případě prázdného 1.arg (key) defaultně prim.klíč (a nebo číslovat od nuly-další možnost)
• na to převádění na pole ($r->toArray()) byl asi návyk z dibi. Velmi se mi to hodí př experimentech.

  Jinak je pravda, že iterator_to_array() to řeší, ale fluent rozhraní je přeci lepší.

Dotaz tag-author

Číst celé, je tu 1 ihned funkční řešení, 1 rádoby bug a druhé řešení, které by bylo nebýt bugu

SQL dotaz jsem si napsal: (duplicitní chování jako výše se vyvolá smazáním kouzelného slůvka distinct)

-- 1. metoda
select distinct tag.*, author.*
from tag
join book_tag on tag.id=book_tag.tag_id
join book on book_tag.book_id=book.id
join author on book.author_id=author.id
order by tag.id
-- 2. metoda, jako  bonus muzeme zjistit agreg.
select  tag.*, author.*,count(*) as kolikKnihDanehoAutoraDanehoTagu
from tag
join book_tag on tag.id=book_tag.tag_id
join book on book_tag.book_id=book.id
join author on book.author_id=author.id
group by tag.id,author.id
order by tag.id

Mimochodem zápis v ND vypadá :

//1a bez distinct vypisuje duplicity
foreach ($connection->table('tag') as $tag) {
	echo $tag->name;
	echo ":::<br>";
	foreach ($tag->related('book_tag')->select(' (book.author.name) AS q') as $value) {
		echo $value->q;
		echo "<br>";
	}
	echo "<br>";
}



//1b zkusim distinct, ale shori to na tom, ze keyword distinct musi byt prvni
foreach ($connection->table('tag') as $tag) {
	echo $tag->name;
	echo ":::<br>";
	foreach ($tag->related('book_tag')->select(' DISTINCT (book.author.name) AS q') as $value) {
		echo $value->q;
		echo "<br>";
	}
	echo "<br>";
}

//SELECT `book_tag`.`tag_id`, distinct(`author`.`name`) AS `q`
//FROM `book_tag`
//LEFT JOIN `book` ON `book_tag`.`book_id` = `book`.`id`
//LEFT JOIN `author` ON `book`.`author_id` = `author`.`id`
//WHERE (`book_tag`.`tag_id` IN (21, 22, 23, 26))
//........................1064 You have error in your

//SELECT distinct(`author`.`name`) AS `q`,`book_tag`.`tag_id`
//zbytek stejny
//funguje!



//podarilo se mi to vyresit i 2. metodou group
foreach ($connection->table('tag') as $tag) {
	echo $tag->name;
	echo ":::<br>";
	foreach ($tag->related('book_tag')
		->group('tag.id,book.author.name')
		->select('book.author.name AS q, count(*) AS c')
		as $value) {
		echo $value->q;
		echo $value->c;
		echo "<br>";
	}
	echo "<br>";
}

ad 1-distinct)Je možné upravit Selection, aby dával distinct na první místo?

Pozn- obě metody (distinct a group) jsou totožné dle explainu.
Stojí tohle za to dát do kuchařky(2.metodu)?

Editoval bojovyletoun (3. 5. 2012 0:48)

Dotaz tag-author

Jediné správné řešení™ je toto: (přesně odpovídá konvencím z přenášky):

$tagsAuthors = array();
foreach ($connection->table('tag') as $tag) {

	$book_tags = $tag->related('book_tag')
	                 ->group('tag.id, book.author.id')
	                 ->select('book.author_id')
	                 ->order('book.author.name');

	foreach ($book_tags as $book_tag) {
		$tagsAuthors[$tag->name][]
			= $book_tag->ref('author', 'author_id')->name;
	}

}

O toto jsem se včera snažil, ale už jsem na to neměl síly. Díky moc @bojovyletoun za navedení :)
Generuje spravně jen 3 optimální dotazy, při joinech zahovává princip šahání do indexu a správně umožňuje dekompozici do entit.

Editoval hrach (3. 5. 2012 10:29)

Akorát můžeš vysvětlit konstrukci $book_tag->ref('author', 'author_id'); – ta vazba z book_tag na autora je na mě moc magická

.Odebral jsem order.jo a ještě jedna věc- záměna podtržítek za tečky v group způsobuje přidání/odebrání joinů.(v druhém dotazu) (Otázka je, zda to může způsobit neplechu, např, když je nějaká kolekce prázdná). Informativní počty joinů(s tečkami oboje řešení 3 joiny, s _ 2joiny/1join)
Pro jistotu ještě zrekapituluji oba kódy:

//bojovyletoun
foreach ($connection->table('tag') as $tag) {
	echo $tag->name, ": ";
	$book_tags = $tag->related('book_tag')
		->group('tag_id, book.author_id')
		->select('book.author.name AS name');
	foreach ($book_tags as $groupAuthor) {
		echo $groupAuthor->name, " ";
	}
	echo "<br>";
}

echo "<br><br>";

//jan
foreach ($connection->table('tag') as $tag) {
	echo $tag->name, ": ";
	$book_tags = $tag->related('book_tag')
		->group('tag_id, book.author_id')
		->select('book.author_id') ;
	foreach ($book_tags as $book_tag) {
		echo $book_tag->ref('author', 'author_id')->name, ", ";
	}
	echo "<br>";
}

Editoval bojovyletoun (4. 5. 2012 13:13)

tak jsem nějak nepřečetl, že jsi ten bug taky fixnul a já se to rozhodl prozkoumat, takže jsem taky transponoval záznamy v structure->hasMany (aby klíče pole byly sloupce a hodnoty tabulky) a pak ještě řešil prioritya v tom se rozhodl podívat no forum a zjistil, že si to vyřešil…

Jo ještě si nevím rady s poslední věcí: stejný příklad: u tagu vypsat ke každému autorovi počet knih pomocí API

foreach ($connection->table('tag') as $tag) {
	echo "{$tag->name},({$tag->related('book_tag')->count('*')} #books, ";
	$book_tags = $tag->related('book_tag')
		->group('tag_id, book.author_id')
		->select('book.author_id, count(*) AS countInSql'); // count je tu jen, aby byl vidět cíl snažení
	echo "{$book_tags->count()} #authors), ";
	foreach ($book_tags as $book_tag) {
		$author = $book_tag->ref('author', 'author_id');
		//echo "{$author->name}({$book_tag->countInSql}), ";
		echo "{$author->name}({?}), "; // jak vypsat počet knih daného autora a tagu
	}
	echo "<br>\n";
}

PHP(5 #books, 2 #authors), Jakub Vrana(3), David Grudl(2),
MySQL(2 #books, 2 #authors), Jakub Vrana(1), David Grudl(1),
JavaScript(1 #books, 1 #authors), Jakub Vrana(1),
VVV(0 #books, 0 #authors),

Editoval bojovyletoun (6. 5. 2012 18:15)