Nextras\ORM – ORM nad Nextras\Dbal

@goood no na action tu kaskadu nemej, ne? vzdy ji mej jen v tom smeru, ve kterem ji potrebujes.

@goood & @Vastlik opraven bug, kdy nebylo mozne smazat enetity bez cascady, ikdyz v non-nullable relationship zadne propojene entity nemela. https://github.com/…a12ed09b7b40

hrach napsal(a):

@goood & @Vastlik opraven bug, kdy nebylo mozne smazat enetity bez cascady, ikdyz v non-nullable relationship zadne propojene entity nemela. https://github.com/…a12ed09b7b40

Nakonec vůbec nemažu akorát zaznamenávám změnu. Ale jinak díky za tvoji (a Honzi Tvrdíka) práci! Je to fakt super!

Hoj, malá drobnost class PersistanceHelper fce addRelationtionToQueue asi malý překlep ;)

PS: dííííky za orm – zatím super!

Editoval namoR (16. 2. 2016 15:18)

@namoR diky, opraveno :)

@namoR delas to spravne, staci pretizit tu metodu. Kvuli tomu tam je :-) cca timto zpusobem :) https://github.com/…esMapper.php#…

Zdravím, potřeboval bych vytvořit entitu s translated properitami. V databázi mám vždy 2 tabulky – jednu pro nepřekládané položky a druhou pro překládané položky (např product a product_translation). Jde mi o podobné chování jako je třeba zde

https://github.com/…nslatable.md
nebo zde
http://propelorm.org/…rs/i18n.html

Předpokládám, že už někdo musí mít toto vyřešené v NextrasORM. Potřeboval bych poradit jak na to a jestli je to možné jednoduše implementovat v NextrasORM

Ahoj,
na Nextras/ORM jsem chtěl přejít z NDB (ačkoliv se mi její koncept náramně líbí a rve mi to srdce, když ji musím opustit) a po vyzkoušení YetORMu, protože ORM nějakým způsobem potřebuji. Ačkoliv se mi na první pohled Nextras/ORM zalíbil (např. IRelationshipCollection::set vidím nějak slušně vyřešené poprvé), už po prvním odzkoušení mě zarazilo několik pro mě dost zásadních věcí:

• Neúplný Debug Bar – dost mi zde schází počet vrácených řádků a EXPLAIN. Obojí jsem dost často v NDB využíval. Proč to není i zde?
• Přenášení všech sloupců a ne jen těch potřebných (jako to umí NDB). Proč se to sem nedochovalo? S názorem, že je žádoucí mít inicializovanou celou entitu nesouhlasím. Na co mi budou data, která nikde nevyužiji?
• „Repository API“ neumí takovou základní věc jako filtrovat podle OR (s tímhle měl problém i YetORM, ale šlo to). To kvůli tomu musím do Mapperu?
• Ani QueryBuilder, natož „Repository API“, neumí UNION. Ten neumí ani NDB a já se ptám, jak je bez něj možné optimalizovat tento dotaz (id – PRIMARY, username – UNIQUE): id = 1 OR id = 2 OR username = ‚SuperMartas‘? Už při třech ORech z minimálně dvou sloupců (byť správně zaindexovaných) to totiž databáze nepobírá a bez použití UNIONu mi prohledává všechny řádky, namísto použití indexů.
• Jaký je důvod použití MySQLi místo PDO? Mi to tak trochu přijde jako jít proti proudu…

Předem děkuji za objasnění.

Editoval SuperMartas (29. 2. 2016 20:42)

@SuperMartas diky moc za zpetnou vazbu!

Neúplný Debug Bar – dost mi zde schází počet vrácených řádků a EXPLAIN. Obojí jsem dost často v NDB využíval. Proč to není i zde?

Protoze jsem to nenaimplementoval a nebylo to pro me tolik dulezote. Vic nez Orm je to zalezitost dbalu, ale chapu – zakladam issue: https://github.com/…al/issues/35

Přenášení všech sloupců a ne jen těch potřebných (jako to umí NDB). Proč se to sem nedochovalo? S názorem, že je žádoucí mít inicializovanou celou entitu nesouhlasím. Na co mi budou data, která nikde nevyužiji?

Tato funkcionalita je sice mozna papirove moc hezka, ale v praxi velice komplikujici kod a celou jeho logiku. Dale vyzaduje bud extremni cachovani cesty pomoci debug backtrace, nebo smireni se s prunikem vsechn potrebnych sloupcu, coz ve vysledku nedava vubec zadna pouzitelna data. Pokud se dostavac do extremniho usecasu, kdyz tabulka obsahuje velka data a jejich prenos je zbytecny, doporucuji rozdelit to do dvou tabulek a entity. Bohuzel, toto je cena za Orm. Ciste teoreticky by se nekdy v budoucnu mohla objevit funkcionalita na dvojfazove nacitani entity, ale zatim opravdu low priority.

„Repository API“ neumí takovou základní věc jako filtrovat podle OR (s tímhle měl problém i YetORM, ale šlo to). To kvůli tomu musím do Mapperu?

Zatim bohuzel ano. Buto to v 2.1. Issue uz je nejakou dobu otevrena: https://github.com/…m/issues/105. Prakticky ale takovou fukcionalitu moc nepotrebuju, a kdyz uz, tak stejne by mi Repository interface nestacil.

Ani QueryBuilder, natož „Repository API“, neumí UNION. Ten neumí ani NDB a já se ptám, jak je bez něj možné optimalizovat tento dotaz (id – PRIMARY, username – UNIQUE): id = 1 OR id = 2 OR username = ‚SuperMartas‘? Už při třech ORech z minimálně dvou sloupců (byť správně zaindexovaných) to totiž databáze nepobírá a bez použití UNIONu mi prohledává všechny řádky, namísto použití indexů.

Neumi a ani umet nebude. Urcite ne Repository. A u query builder taky ne, volani metod by melo upravovat pak jakou cast query? Nedavalo by to vyznam. Pouzij union, normalne v mapperu.

Jaký je důvod použití MySQLi místo PDO? Mi to tak trochu přijde jako jít proti proudu…

Nekolik, ale jeden naprosto zasadni: PDO je zprasene. Omezuje te MySQLi nejak konkretne?

@hrach Děkuji za objasnění, jsem rád, že to pomohlo oboustranně. :)

Neúplný Debug Bar

Super. :) Jestli to nestihneš, tak mě to pravděpodobně tak naštve, že to sám implementuji a jestli se mi to bude zdát jako použitelný kód, možná zkusím i nějak přispět. Ale nic neslibuji.

Přenášení všech sloupců a ne jen těch potřebných

OK, to zní docela rozumně a asi to i chápu a dokážu s tím žít. Zatím jsem se do tak extrémní situace nedostal, tak snad to bude OK.

„Repository API“ neumí takovou základní věc jako filtrovat podle OR

Super, snad se to už do té další verze konečně dostane. :D Zatím teda nechávám na Mapperu. Asi ten můj případ bude taky ojedinělý…

Ani QueryBuilder, natož „Repository API“, neumí UNION

Spíš mě napadlo něco jako „spojování kolekcí“, že by se volalo něco jako:

<?php
$collection = new Collection();
$collection->add($this->findBy(["column" => "value"]));
$collection->add($this->findBy(["column2" => "value2"]));
$collection->fetchAll(); // získá data do obou kolekcí přes UNION, resp. to závisí na mapperu (ArrayMapper by to dělal např. přes array_merge())
?>

Ale je to jen návrh, asi by to chtělo nějak víc promyslet, ale základní idea je takováto…

Omezuje te MySQLi nejak konkretne?

Zatím ne, spíš mě to zajímalo, protože co tak pozoruji, tak všichni jedou PDO a, jak už jsem napsal, mi přijde používat MySQLi jako jít proti proudu. Ale osobně nemám nic moc proti.

PDO je zprasene

Máš k tomu nějaké zajímavé čtení nebo čerpáš přímo ze zdrojáků? Docela by mě to zajímalo. Ale asi i já už jsem narazil na lehkou zprasenost – při UniqueContraintViolationException v NDB jsem nenašel jiný způsob, jak získat alespoň jméno „porušeného“ klíče, než vyparsovat ho ze zprávy výjimky. Ale nejsem si jistý, jestli to není kvůli MySQL. Nemá na to něco lepšího MySQLi, resp. Nextras/ORM?

A v PDO to jde nejak ziskat? Toto muze byt urcite dalsi feature request.

Napsal jsem si na to takovou malou třídu. Sice je to pro NDB, ale ta zpráva, ze které to beru, bude nejspíš pro PDO stejná. Tak pro inspiraci:

<?php
public function __construct(UniqueConstraintViolationException $exception)
{
	if ($exception->errorInfo[1] !== 1062)
		throw new InvalidArgumentException("Code is not 1062");

	if (!preg_match("~'(?P<value>.*)' for key '(?P<key>.*)'$~", $exception->getMessage(), $matches))
		throw new InvalidArgumentException("Message has an invalid format");

	$this->key = $matches["key"];
	$this->value = $matches["value"];
}
?>

Jestli chceš založit feature request, tak to udělej, já se v tom moc nevyznám…

Našel jsem pár dalších nedostatků.
Mám entitu User a ta má atribut $password. Můj plán byl, že tento atribut bude při čtení vracet uložené zahashované heslo, tedy to samé, co je v databázi. Zapisovat se do něj ale bude plaintextové heslo, které se následně v setteru okamžitě zahashuje. Nenašel jsem způsob, jak toho rozumně dosáhnout, protože se při čtení volá setter, ač to zní dost podivně, ale přesto je to logické z principu fungování. Heslo je tak zahashované podruhé, což je nežádoucí.
Zkoušel jsem to obejít trochu nepohodlně přes read-only property $passwordHash, která by vracela právě ten hash hesla, který je i v databázi, a virtuální write-only property $password, jejíž setter by zapisoval zahashované heslo do $passwordHash. Ale zde nastávají další problémy:

1. Do read-only property nelze zapisovat a to dokonce ani ve třídě, která ji vlastní!
2. Write-only properties nejsou implementovány nebo mi z nějakého důvodu nefungují.

Docela mě zaráží, že takové podle mě základní věci nejsou na spoustě místech vyřešeny, případně se s nimi ostatní programátoři nesetkali. Možná to dělám špatně jen já, což je velmi pravděpodobné. :D
To mě přivádí na otázku: existuje (na GitHubu) nějaký volně dostupný reálný projekt, který používá Nextras/ORM, abych se mohl inspirovat? Zatím jsem našel pouze Componette, ale chtělo by to něco víc…

To nekonzistentní čtení a zápis mně osobně zase tak divné nepřijde, ale ohledně toho mám ještě spoustu dalších otázek, které by tu nebylo vhodné probírat, takže na to založím vlastní téma. Ale jinak super, díky, pomohlo.

@SuperMartas jo a prosim nezakladej nova vlakna :-) bud tu, nebo klidne na githubu. (tam radej spis anglicky :-))

Ad setovani password: da se na to divat taky tak, ze hashovani hesla je proste funcionalita, kterou zabalim do servisni tridy. Respektive ji bude provadet v service RegisterNewUserService. Tak to resim ja.

Editoval hrach (2. 3. 2016 13:26)

@mates byt nevim co presne myslis, tak ani u orm ani u dbalu nedoslo k zadnym zmenam, takze funguje to tam uplne stejne :-)

@mates transakce funguji uplne stejne. tj. to co chces dosahnout, to tak opravdu funguje a bude v poradku.

co se tyce api, na cem se vola persist – to stare funguje a porad bude, to nove ti umozni to delat primo na modelu. prakticky jsou ale vnitrnosti stejne dost prepsane, a ohledne persistovani je dost zmena v kaskade, tj. je urcite si nastudovat definini relatioship properties.

@Vastlik jestli to dobre chapu, tak ten screen je z mapperu. tj. musis udelat nad repository anotaci @method, aby udelal proxy. viz. dokumentace: https://nextras.org/…0/repository

@hrach Tj. chce se vyhnout hydrataci a dost možná vůbec nepoužít ten builder.

@Vastlik aha, nepodival jsem se poradne, co tam delas. Muzes si tedy napsat vlastni proxy. (v repository zavolas $this->mapper->getSum...()). Nicmene, protoze to nema moc co delat s Orm, normalne bych to presunul do vlastni servisni tridy, ktera jako dependency bude mit Connection.

@Vastlik nechapu, co, nechapes. zpusob implementace automaticke proxy, vlastni proxy, hydratace, ci navrhovaneho reseni?

Reseni:

class MyClass
{
	private $connection;
	public function __construct(Nextras\Dbal\Connection $connection)
	{
		$this->connection = $connection;
	}
	public function findSumById()
	{
			$this->connection->createQueryBuilder()->select()->from()...
	}
}

Ad proxy: no proste pokud mas metodu v mapperu, tak se k ni pres repository dostanes pomoci proxy metody, ne?

class UsersRepository
{
	public function findSumBy(...$args)
	{
		return $this->mapper->findSumBy(...$args);
	}
}
$orm->users->findSumBy();

Ahoj,
mám Entitu ve které mám

 * @property-read DateTime $expirationDate {virtual}
 * @property DateTime $createdAt {default 'now'}
 * @property VoucherType $voucherType {m:1 VoucherType::$vouchers}
.
.
.
protected function getterExpirationDate()
    {
        $currentDate = $this->createdAt;
        return $currentDate->add(new \DateInterval('P'.$this->voucherType->validity.'D'));
    }

Ale tato funkce ovlivňuje i property createdAt. Tzn., že pokud se snažím získat entitu, tak createdAt == expirationDate.
Pokud vymažu funkci getterExpirationDate, tak se createdAt změní zpátky na správnou hodnotu, která je v DB.

Editoval Vastlik (19. 3. 2016 11:35)

@hrach Moc díky :)

goood napsal(a):

ahoj, jsem asi trošku natvrdlej, nebo nevím.
V mapperu si pomocí builderu stavím dotaz

<?php
public function findByEventId ( $eventId ) {
	return $this ->builder() -> select('company.*') ->from('action') -> innerJoin ('action', 'company', 'company', 'action.company_id = company.id') -> where('event_id = ' . $eventId) -> groupBy( 'company_id');
}
?>

Ale vygenerovaný dotaz vypadá takto:

SELECT ``.* FROM action INNER JOIN company AS `company` ON (action.company_id = company.id) WHERE event_id = 12 GROUP BY company_id

Chtěl bych aby výsledek byl

SELECT company.* FROM action INNER JOIN company AS `company` ON (action.company_id = company.id) WHERE event_id = 12 GROUP BY company_id

Co dělám prosím špatně?

Zajímavé je, že takto to funguje, ale ne efektivně

<?php
return $this ->builder() -> select('[c.*]') -> from('[company]', 'c') -> innerJoin ('c', '[action]', 'a', '[a.company_id] = [c.id]') -> where('[a.event_id] = ' . $eventId) -> groupBy( 'company_id');
?>