Nextras\ORM – ORM nad Nextras\Dbal

@Hanz25 ano, v mapperu pretizis metodu, viz. doc https://nextras.org/…/conventions#…

@meridius problem je, ze pak by ti takova metoda nemusela fungovat v testech, respektive bys ji musel implementovat i pro array mapper :)

Ahoj,

plánujete i do trojky zařadit podporu víceslovných camel case názvů entit/repo/mapperů ?

Několikrát jsem to zkoušel a myslím, že to failuje někde v mapperu, kdy to ten název vždy přepisuje na ucfirst název.

Díky :)

Editoval Hanz25 (15. 5. 2017 13:55)

@hrach Aha, já myslel, že pro to prostě není podpora. Ok, zkusím to jestli to nebude fungovat, hodím to do issue

Zdravím, mám jenom dotaz ohledně removeAndFlush() pokud to zavolám nad Entitou která má cizí klíče, tak pro mě tam jsou zbytečně selecty na tabulkami právě těch cizích klíčů (další dotazy navíc), které se vygenerují před transakcí, dá se to případně nějak zakázat?

Ahoj,

tabulky vypadají oka, ale ta definice entity je taková mírně zmatečná. Definuješ zvlášť ten klíč jako obyčejný int sloupec a zároveň jako další property, která je ovšem vztahem.

Já bych definici té entity upravil takto

/**
 * Category
 * @property int $id {primary}
 * @property string $name
 * @property Movie[]|NULL $movies {1:m Movie::$category}
 */

/**
 * Class Movie
 * @property int $id {primary}
 * @property string $title
 * @property Category $category {m:1 Category::$movies}
 * @property string|NULL $content
 * @property int|NULL $csfdId
 * @property string|NULL $year
 * @property DateTimeImmutable $createdAt
 * @property Comment[] $comments {1:m Comment::$movies }
 * @property Tag[] $tags {m:m Tag::$movies, isMain=true}
 */

– odstranil jsem statementy OneHasMany a ManyHasOne – jsou nepovinné a zhoršují čitelnost (úplně nevím proč tam jsou)
 – sjednotil jsem property $cat a $category do jedné. Nemá cenu (a ani to snad nejde) to definovat ve dvou propertách, protože pokud chceš jen ten int, tak se dá nad property zavolat getRawValue().
 – odstranil jsem závorky [] u property category (původně cat), protože odkazuješ na jednu entitu a ty závorky značí že jich bude víc, tedy odkazují na kolekci

@revager v UserReservation by se property mely jmenovat bez suffixu _id (pokud je nastaven v db spravne cizi klic). Viz dokumentace https://nextras.org/…/conventions#…

Ahoj,

existuje někde ukázka implementace property container? Pořád kolem téhle featurky chodím, ale nevím úplně přesně jak funguje a jak by se dala implementovat.

Zdravím setkal se někdo s problémem že když nastavím
dbal:
simpleStorageTz: ‚Europe/Prague‘

tak DateTime který vytvořím a uložím do DB je v pořádku, ale když ho načtu tak mám –2h.

Když ten simpleStorage nepoužiji, tak se mi od DB DateTime uloží o –2h. ale zas načte (v PHP) v klasickém času, nějáké nápady jak tohle vyřešit?

Jo, to mám také.

Sem tam se mi to podaří někde vychytat když zkouším různé kombinace, ale ne všude mám povoleno instalovat mysql timezony. A když se mi to podaří vychytat tak to samé nastavení nefunguje i jinde.

Editoval Hanz25 (24. 7. 2017 11:58)

Podstatný je, jaký typ sloupce používáš. MySQL nebo PostgreSQL se pak chovají jinak a orm se tomu prizpusobi. Nicméně od verze 3.0 by se to mělo chovat inteligentneji.

Pokud byste chtěli poradit, hoďte sem svojí konfiguraci orm, timezonu ve které běží MySQL, ve které běží php, typ sloupců.

@DavidKlouček

Jakej je vlastně cíl Nextras\ORM?

Dodat kvalitni ORM pro PHP.

Když má identity mapu a je to teda plnohodnotný ORM, je nějakej důvod ho použít místo nejrozšířenější Doctrine 2?

Urcite. Doctrine2 ma plno vlastnosti, ktere nemuseji vyhovovat. Uz jsem se o tom nekde rozepisoval, ale nemuzu to ted najit. Osobne mi na Doctrine nevyhovuji tyto vlastnosti, ktery ma nextras poreseny:

• lazy loading relationships: v Doctine to napriklad nefunguje u ManyHasOne.
• clever loading of relationship: v Doctrine na to musis myslet dopredu, v Nextras mas na repository definovany obecny gettery, vede to k trochu vic reusable architekture.
• definice entity: je to dost vec vkusu, ale v Nextras se vleze na screen, takze se lepe ziska prehled
• edge case vlastnosti: napr. v Doctrine nelze u MySQL ziskat id, nez udelam flush, protoze persist realne nevola jeste dotaz (insert) do db. Takova blbost, ale dost dulezita. U Postgre se chova Doctrine lepe diky sekvencim.

A ještě jedna věc, proč snad u všechny ORM autorů z Nette komunity používaj poddotazy místo joinů?

U Nextras se poddotazy naopak nepouzivaji. (Temer, jediny pouziti je pro nektere count dotazy, ale tam by join jaksi moc nepomohlo.) Pro filtering se pouziva join, pro vybrani dat se pouzivaji nove dotazy. Ale to nejsou poddotazy. :)

Editoval hrach (24. 7. 2017 20:23)

zdravim,

ako v teste vytvorim entitu bez hlasky:
Nextras\Orm\InvalidStateException: MetadataStorage::get() called too early.

Been there: https://github.com/…m/issues/181

Aktualne to neni mozne, ale premyslim o tom, ze bych neco maleho sesmolil, aby to slo. :-)

nj, to som nasiel, kym som sem napisal. akurat mi neslo do hlavy, ze to je rok stare.

to sa fakt neda nejako normalne napisat unit test s entitou?

to sa fakt neda nejako normalne napisat unit test s entitou?

@stajo on to pak neni moc unit test, kdyz tam passujes celou Entitu. Tak tam posilej IEntity, respektive mock tve entity.

Proste aby ORM dobre fungovalo a bylo propojene s ostatnimi entitami, potrebuje mit dobra metadata, a ty neni jednoduche vytvorit. Obecne by me zajimalo, jak ten test presne pisete? @Felix

Editoval hrach (13. 8. 2017 14:49)

Ahoj, chtěl jsem se zeptat, zda lze pomocí Nextras\Orm jednoduše získat i výsledek dotazu s agregační funkcí, nebo musím položit dotaz přes Nextras\Dbal\Connection. Jde mi o to, že chci zjistit MAX(hodnotu) a MIN(hodnotu) sloupce v tabulce a nejraději bych to měl v repository jako metodu, ale patrně by to pak popíralo smysl ORM.

Díky

@DavidMatějka Díky za nasměrování. Nakonec jsem našel example zde: https://nextras.org/…2/repository#…

@Hologos DbalMapper vyuzival Nextras\Dbal\Connection, takze si normalne nech nawirovat pres DI tuto tridu.

Ahoj,

mám obrovský problém s výkonností ORM. Udělal jsem sample aplikaci, kde trasuju časy. Na lokálu je PHP 5.6.31, na hostingu 5.6.30. Používám Nextras/ORM 2.2 a Nextras\Dbal 3.0.

V DB jsou 2 tabulky Set a Cards. Tabulka sets má 1 záznam, tabulka cards má asi 300 záznamů.

Entity

<?php

namespace App\Model\Orm;

use Nextras\Orm\Entity\Entity;
use Nextras\Orm\Relationships\OneHasMany;

/**
 * @property int                $id {primary}
 * @property string             $code
 * @property string             $name
 * @property string             $type
 * @property DateTime           $releaseDate
 * @property int                $active {default self::NOT_ACTIVE}
 * @property OneHasMany|Card[]  $cards {1:m Card::$set, orderBy=name}
 */
class Set extends Entity
{
    const NOT_ACTIVE = 0;
    const ACTIVE = 1;
}

/**
 * @property string         $id {primary}
 * @property string|NULL    $multiverseId
 * @property string         $name
 * @property string|NULL    $number
 * @property string|NULL    $imageName
 * @property string         $rarity {enum self::RARITY_*}
 * @property int            $active {default self::NOT_ACTIVE}
 * @property Set            $set {m:1 Set::$cards}
 */
class Card extends Entity
{
    const NOT_ACTIVE = 0;
    const ACTIVE = 1;

    const RARITY_COMMON = 'c';
    const RARITY_UNCOMMON = 'u';
    const RARITY_RARE = 'r';
    const RARITY_MYTHIC = 'm';
    const RARITY_SPECIAL = 's';
    const RARITY_BASIC_LAND = 'b';
}
?>

Tabulky mají v databázi indexy:

sets
PRIMARY id
UNIQUE code
INDEX type
INDEX release_date

cards
PRIMARY id
INDEX set, name
INDEX name

<?php
$sets = $this->orm->sets->findBy(['type' => 'expansion'])->orderBy('releaseDate', ICollection::DESC);

Debugger::timer('overall');

foreach($sets as $set)
{

    Debugger::timer('cards');
    $cards = $this->sets->cards;
    foreach($cards as $card) {} // aby se provedlo načtení
    Debugger::log('Retrieving cards took '. number_format(Debugger::timer('cards'), 2, ',', ' ') .'s.');

    foreach($cards as $card)
    {
        // zatim neni potreba resit
    }
}

Debugger::log('Overall time '. number_format(Debugger::timer('overall'), 2, ',', ' ') .'s.');
?>

A výstup je

<?php
Retrieving cards took 6,53s.
Overall time 6,68s.
?>

Zkoušel jsem to nahrát i na hosting, a tam jsou časy ± totožné. Zajímavé je, že když se podívám to Tracy DebugBaru, tak tam ty SQL dotazy se vykonaj za pár milisekund. Jestli to chápu správně, tak má takovou režii samotný ORM framework? Cílový stav aplikace, že tabulka sets bude mít cca 400 záznamů a tabulka cards bude mít cca 35 000 záznamů. Pokud by časy ještě více stoupaly, tak to je skoro neúnosné.

<?php
SQL query	Time (ms)
SELECT `sets`.* FROM `sets` AS `sets` WHERE `sets`.`type` = 'expansion' ORDER BY `sets`.`release_date` DESC	0.423
SELECT `cards`.* FROM `cards` AS `cards` WHERE `cards`.`set` IN (1) ORDER BY `cards`.`name`	0.730
?>

Editoval Hologos (18. 9. 2017 14:35)

Zdravím chci se zeptat zda-li se někdo nesetkal s tímto problém. Jde o to že vybírám velké množství řádku (cca 25k) a limituju to třeba na 1000, dotaz je rychlý v clientu a v tracy taky, cca 16–20ms (je tam hodně joinu) ale pokud si to profiluju (i na produkci), tak se dostanu na 200–300ms konkrétně tahle část

$result = $this->connection->queryArgs($builder->getQuerySql(), $builder->getQueryParameters());

Pokud dotaz napíšu klasickým query je výsledek totožný. Není tam nějáký problém s „LIMIT“ ?

Editoval Lizardor (21. 9. 2017 16:57)

Mám vzťah M:1, názov stĺpcu v zdrojovej tabuľke je user_account_id, názov property musím mať $userAccount, používam prefixy aj v iných tabuľkách.

* Class UserMessage
* @property User $user {m:1 User::$messages}

* Class User
* @property UserMessage[]|NULL $messages {1:m UserMessage::$user}

//Result: UserMessage::$user is not nullable

//funguje OK
* Class UserMessage
* @property User $userAccount {m:1 User, oneSided=true}

V createStorageReflection volám setMapping a zmením názov, nejaký iný elegantnejší spôsob ? :)

Editoval majky358 (25. 9. 2017 16:26)

Ahoj, narazil jsem na jednu takovou WTF vlastnost, která snad ani není bug, jen prostě… WTF.

Jde o to, že v některých situacích čtení z property zavolá její setter.

__get() → getValue() → internalGetValue() → initProperty() → internalSetValue() → setter*()

Což může vést k zajímavým „efektům“, např.:

<?php
/**
 * @property int $id {primary}
 * @property OneHasMany|Child[] $children {1:m Child::$user}
 */
class User extends Entity {}

/**
 * @property int $id {primary}
 * @property User $user {m:1 User::$children}
 * @property string $personalId
 */
class Child extends Entity {

	public function __construct(User $user, $personalId) {
		$this->user = $user;
		$this->personalId = $personalId;
	}

	protected function setterPersonalId($value) {
		$this->throwIfDuplicate($value);
		return $value;
	}

	private function throwIfDuplicate($personalId) {
		foreach($this->user->children as $child) {
			if($child === $this) {
				continue;
			}
			if($child->personalId === $personalId) { // problém - zavolá setterPersonalId nad $child a spustí celý kolotoč znovu
				throw new DuplicateChildException;
			}
		}
	}

}
?>

Nejspíš to jen blbě používám, ale každopádně mi to přijde, že se taková chyba může stát každému celkem snadno. Mít validaci v setteru mi přijde logické (resp. jde o pochopitelný zvyk z klasických public setterů), naopak bych nečekal, že se bude volat setter když čtu – nicméně ono to zjevně svůj důvod má, proto mi to vlastně nepřijde jako bug a hádám, že to není rozumně řešitelný.

Jinak musím ORMko pochválit, jedním očkem sleduju vývoj od začátku (fíha, to už uběhly 3 roky?) a vypadá super! Na menší projekty kde člověk nechce vytahovat Doctrinu vypadá jako velmi dobrá volba. Díky :-)

Editoval Zax (28. 9. 2017 0:40)

Zdravím,
prosím vás čo robím špatne na používaní builderu v maperi?

public function findMedicalPlansToProgressComponent(  )
{
	$this->builder()
		->andWhere('start < %dt', DateTime::from('now'))
		->andWhere('end > %dt', DateTime::from('now'));

	return $this->builder();
}

Ono to vracia kolekciu ale vôbec to neberie do úvahy tie podmienky.
Vypadne z toho sql

SELECT `medical_plans`.* FROM `medical_plans` AS `medical_plans`

A to ešte netuším ako do toho dostanem join …

Editoval Čamo (3. 10. 2017 16:39)

@Zax yes, to je aktualni chovani a je o tom, ze proste nacitani dat z db musi projit setterem (aby se treba nejaka data znormalizovala). Mel jsem pocit, ze uz jsem kolem toho neco resil do 3.0, ale nemuzu ted najit zadny konkretni commmit. Mozna by se to mohlo nejak zmenit. Muzes zkusit pouzit metodu getRawValue(), ktera nespusti ten setter (ale muzes dostat nenormalizovanou hodnotu, coz by u stringu ale nemel byt moc problem).

@MilanObrtlík no, dle tveho popisu to podle me je o tom, ze nema mit tagy 1–7, ale jeden tak v 1–7. Jinak nevim, na jake vrstve te to zajima, ale tento konkretni dotaz by mohl byt nasledovne:

$booksRespository->findBy(['this->authors->id' => 1, 'this->tags->id' => [1, 2, 3, 4, 5, 6, 7]]);

@Čamo je to tak :-) Metoda builder() vzdy vraci novou instanci builder.

Ahoj,

narazil jsem na zajímavý problém a nevím, jak je vyřešit. Mám 2 entity, které jsou mezi s sebou 2× provázané vazbou ManyHasMany a generuje mi to pro oba případy shodné názvy vazebních tabulek. Jak z toho ven?

Skupina (Group) může mít 1 až N vlastníků (User) a vlastník (User) může vlastnit 0 až N skupin.
Skupina (Group) se skládá z 0 až N hráčů (User) a hráč může být v 0 až N skupinách (Group).

<?php

namespace App\Model\Orm;

use Nextras\Orm\Entity\Entity;
use Nextras\Orm\Relationships\ManyHasMany;

/**
 * @property int $id {primary}
 * @property ManyHasMany|Group[] $ownedGroups {m:m Group::$owners, isMain=true}
 * @property ManyHasMany|Group[] $groupsIamMemberOf {m:m Group::$members, isMain=true}
 */
class User extends Entity
{

}

/**
 * @property int $id {primary}
 * @property ManyHasMany|User[] $owners {m:m User::$ownedGroups}
 * @property ManyHasMany|User[] $members {m:m User::$groupsIamMemberOf}
 */
class Group extends Entity
{

}
?>

Edit: V jedné přednášce (ještě ke starému Orm) si zmínil, že bys to řešil pomocí více entit. Když nad tím přemýšlím, tak je to tak určitě lepší pro budoucí vývoj, protože se pak může změnit požadavek, že GroupMember nemusí být nutně registrovaný uživatel. I tak to tu nechám, zajímá mě aktuální názor.

Editoval Hologos (13. 10. 2017 9:03)