Ukážeme si, že Doctrine není jenom ORMko a kdy jít o vrstvu níž. Jak DQL naučit věci, které v základu neumí, ale vaše databáze ano. A pár dalších tipů, jak nemít z databáze úplně hloupé úložiště.
Doctrine ◦ indexy pro vazby a primární klíče ◦ vzdálené klíče • Co si musíte pohlídat sami ◦ unique indexy ◦ vlastní typy Pokud se bavíme o nedělání hloupého úložiště z databáze, tak logicky chceme využívat funkce co databáze nabízí. Takový úplný základ jsou indexy a vzdálené klíče. O trochu pokročilejší jsou pak unikátní klíče a vlastní datové typy.
* @ORM\Column(type="uuid") */ private $id; class Order { /** * @ORM\ManyToOne(targetEntity=User::class) * @ORM\JoinColumn(nullable=false) */ private $user; IDčko musíme entitě dát vždy, jinak ji Doctrine nepřijme - tím získáme primární klíče. Když pak děláme vazby pomocí *ToMany nebo *ToOne vazeb, generuje nám Doctrine i vzdálené klíče, k nim indexy a klidně i many to many tabulky.
private $email; Nejjednodušší způsob, jak získat unique klíče, je použít unique vlastnost annotace Column. Doctrine nám pak vygeneruje adektávní schéma.
řešit? ◦ >90% aplikacím stačí check přes repository před flushem ◦ >90% aplikací nikdy nenaroste natolik, aby to byl skutečný problém • Pokud to opravdu opravdu potřebujete řešit ◦ kdyby/doctrine ... NonLockingUniqueInserter ◦ ^ brzy i samostatně, jako kdyby/doctrine-nonlocking-unique-inserter ◦ ^ Symfony friendly ❤ ◦ ^ sledujte issue kdyby/doctrine#238 S unikátními klíči souvisí řešení race conditions. EntityManager se při flushnutí entity, která poruší unique index, kompletně zamkne a není možné s ním dál pracovat. Pro 90% aplikací stačí prostý check repozitářem, že takový záznam v databázi neexistuje. Pokud to však opravu potřebujete řešit, koukněte na issue https://github.com/Kdyby/Doctrine/issues/238, kde se řeší rozdělení Kdyby/Doctrine na framework-agnostic balíčky. Brzy totiž vznikne například kdyby/doctrine- nonlocking-unique-inserter, který tento problém řeší.
= 'uuid'; function getName() { return self::NAME; } function getSQLDeclaration( array $fieldDeclaration, AbstractPlatform $platform); function convertToPHPValue( $value, AbstractPlatform $platform); function convertToDatabaseValue( $value, AbstractPlatform $platform); Zdroj: ramsey/uuid-doctrine Pěkný příklad vlastního typu je UuidType z balíčku ramsey/uuid-doctrine. Viz http://docs.doctrine-project.org/en/latest/cookbook/custom-mapping-types.html
{ function requiresSQLCommentHint( AbstractPlatform $platform) : bool // … $platform->markDoctrineTypeCommented(Type::getType($type)); U vlastních typů je nutné řešit, aby byly správně oanotovány v databázi, protože jinak Doctrine neumí správně diffnout co se změnilo. Pokud však typ označíme, jakože se má komentovat, Doctrine si do komentáře sloupečku tabulky uloží jak se ten typ jmenuje a bude schéma diffovat správně.
Type { function canRequireSQLConversion() : bool; function convertToDatabaseValueSQL( $sqlExpr, AbstractPlatform $platform); function convertToPHPValueSQL( $sqlExpr, $platform); Pokud budete potřebovat pokročilou konverzi binárních dat už na úrovni databáze, slouží k tomu tyto metody.
private $id; CREATE TABLE "user" ( id UUID NOT NULL, email VARCHAR(255) DEFAULT NULL -- atd ); COMMENT ON COLUMN "user".id IS '(DC2Type:uuid)'; Při použití uuid typu na sloupci id se vygeneruje podobné schéma, jako je v pravo.
the root of all evil ~ Donald Knuth O tom, jestli patří logika do databáze nebo do modelu můžeme klidně dál vést svaté války, ale v momentě kdy si jednu z cest zvolíte, měli byste ji co nejstriktněji dodržovat. Já volím logiku v modelu a to znamená, že logice v databázi se budu vyhýbat dokud to bude možné.
a Database statement and therefore bypass any locking scheme, events and do not increment the version column. Entities that are already loaded into the persistence context will NOT be synced with the updated database state. It is recommended to call EntityManager#clear() and retrieve new instances of any affected entity.” ~ Dokumentace Dávejte si pozor, pokud píšete SQL, ale i DQL update a delete dotazy, protože Doctrine nemá jak kontrolovat zamykání a nemá jak poznat, které entity obnovit v paměti. Pokud tedy něco takového pustíte, je doporučováno následně vyčistit entity z paměti a načíst si je znovu.
nad výsledkem ◦ ORM\Query::iterate(); ◦ Stránkování • Raději DQL update, než SQL update • Neumí JOINy :( Předtím než se uchýlíme k DQL updatu, tak je vhodné nejprve zkusit, jestli by nestačilo udělat nějakou chytřejší iteraci nad daty. Buď tedy nějaké custom stránkování výsledků, nebo použití metody iterate(), která umí hydratovat entity postupně a snižujeme tím šanci, že nám dojde paměť, ikdyž potřebujeme zpracovat miliony entit. Jedna z nevýhod ale je, že UPDATE ani DELETE neumí JOIN.
->andWhere('orderItem.order = theOrder.id'); $update = $em->createQueryBuilder() ->update(Order::class, 'theOrder') ->set('theOrder.totalPrice', sprintf('(%s)', $select)) ->getQuery(); Ovšem to že neumí JOINy se dá celkem snadno řešit pomocí subselectů.
se nejde vyhnout použití SQL na batch operace a pokud to opravdu dává smysl, tak není důvod kvůli tomu skřípat zuby. Práci by vám mohl usnadnit chudší bratříček DibiFluent, tedy QueryBuilder v DBAL.
SqlWalker - generuje samotný SQL dotaz • vlastní funkce TreeWalker umí modifikovat načtenou strukturu DQL dotazu do stromu objektů, které ho reprezentují (AST) a modifikovat jej. Output SqlWalker umí převést AST na SQL a když si tento výchozí podědíte, můžete si změnit způsob jakým se výsledné SQL z AST DQLka skládá.
NULL AS something FROM ...; Tam musí funkce SELECT IS_NULL(order.finishedTime) AS something FROM ...; Funkce je ovšem možné doplnit téměř kamkoliv a chybějící syntax tedy ve výsledku není problém, protože identickou funkcionalitu snadno doplníme.
$expression; public function getSql(SqlWalker $sqlWalker) { return $sqlWalker->walkArithmeticPrimary($this->expression) . ' IS NULL'; } public function parse(Parser $parser) { $parser->match(Lexer::T_IDENTIFIER); $parser->match(Lexer::T_OPEN_PARENTHESIS); $this->expression = $parser->ArithmeticPrimary(); $parser->match(Lexer::T_CLOSE_PARENTHESIS); } Vlastní funkce do DQL musí mít minimálně metodu parse(), která tokeny v DQL převede na node v AST a funkci getSql() která zpracovaný node převede na SQL.
My\Employee employee; SELECT employee, WINDOW_OVER(AVG(salary), employee.department) AS avgSalary FROM My\Employee employee; SELECT employee, WINDOW(AVG(salary) OVER (PARTITION BY employee.department)) AS avgSalary FROM My\Employee employee; Rozšiřování DQL: komplexnější syntaxe První ukázka AFAIK není možná docílit, protože mění syntaxi DQL, druhá a třetí ale je, protože naše speciální syntax je obalená do custom funkce.
(PostgreSQL) • beberlei/DoctrineExtensions (MySQL, Oracle) • syslogic/doctrine-json-functions (MySQL) • další na: https://packagist.org/search/?q=dql Pár zajímavých balíčků, kde jsou již naimplementovány užitečné funkce do DQL.
(mixed results) ◦ ORM\Query::getResult(); • array - vytvoří strukturu jako pro entity a tu vrátí ◦ ORM\Query::getArrayResult(); • scalar - přejmenuje sloupce na fieldy a přetypuje ◦ ORM\Query::getScalarResult(); Né vždy je potřeba hydratovat entity, když bych z nich zase mapoval hned pole, protože je chci jen číst. Dávejte si ale pozor na vracení výsledků z databáze rovnou jako struktury z API, změnou entit a nebo dotazu si tak snadno rozbijete kompatibilitu API.
->from(...) $em->createNativeQuery($sql, $rsm) Pokud potřebujete opravdu složité filtrační dotazy, které ale chcete zpracovávat jako entity, můžete použít Native Queries, které umožňují napsat libovolné SQL a převést výsledek na entity, stejně jako by to dělala Doctrine.
dokud to jenom trochu jde • Nebát se využívat hojně vlastní typy • Rozšiřování DQL je snadné • Doctrine není určená na batch operace Kam dál? • Youtube kanál “Nette Framework” > search “Doctrine”
fprochazka
andpad
yokawasa
databricksjapan
kwappa
maimyyym
lycorptech_jp
riyaamemiya
sansantech
bobtani
koki_nishihara
nakasho
layerx
mclloyd
eitanlees
chrislema
searls
akosma
thekraken
keavy
paigeccino
hursman
brettharned
eileencodes
sachag
