Nextras\ORM – ORM nad Nextras\Dbal

Ta tam je, to je ta první entita

@Matey Dííík! To pomohlo. Jen nerozumím tomu proč je to potřeba, když u jiných vazeb to potřeba nebylo…

Nebude problém hlavně v použití skloňovače (oodle/inflect)?

• https://github.com/…/Inflect.php

Ten totiž (správně) udělá tohle :)

• ‚person‘ ⇒ ‚people‘

Edit1: Takže správně by měla být entita ContactPerson a repo ContactPeople :)

Edit2: aha, ok

Editoval Gappa (4. 6. 2015 9:08)

@hrach Jenom se chci ujistit, kdyz mam m:n tabulku a v ni nejakou dalsi logiku. Treba specialni ikonku a poradi. Tak musim udelat specialni entitu, repository i mapper. Je to tak?

@hrach Moc díky za to skvělé ORM, moc pěkně se s tím dělá!

Chtěl jsem se zeptat, jestli není už někde implementovaný DataSource ORM pro Nextras DataGrid, nebo jestli někdo neimplementoval DataSource pro Mesour DataGrid

Vysla RC verze 1.1. https://github.com/…g/v1.1.0-RC1
Novinky:

• plna podpora pro Single Table Inheritance
• intuitivnejsi zapis relationship v entitach
• convertory na mapper vrstve pro data z/do db. Diky tomu neni problem pouzivat v postgre jsonb, nebo nejake vlastni typy na booleany, apod.

@Hologos nehledě na počet tabulek, podle mne je to spíše o logice. Myslím, že Nextras ORM je lepší na běžný CRUD a menší věci, Doctrine se hodí na složitější logiku (například eventy, a podobné věci). Navíc doctrine umožňuje např. one to many jednosměrné asociace ze strany one tabulky. Ale to je opět taková specifická věc, která se využije jen málokdy.

Aha. Z ukázky Honzy Tvrdíka na nette campu jsem získal dojem, že je to spíš na takové hodně rychlé prototypování než na pořádnou logiku. I Honza sám tam říkal, že doctrine je více domain driven než nextras orm. Ale je možné, že jsem to blbě pochopil a v tom případě se omlouvám, ale rád bych si vyslechnul váš názor na to, jak Honza Tvrdík říkal, že doctrine je více domain driven než nextras orm a co z toho vyplývá.

Jaké velké projekty běží na nextras orm?

Kde přesně je ta velmi dobrá podpora eventů? Prolétl jsem dokumentaci a nikde jsem o nich nenašel žádnou zmínku (eventy jako postLoad, postFlush, a podobné).

Editoval Azathoth (8. 9. 2015 0:49)

@Azathoth hm, neni v doc → neuvedomil jsem si:

• eventy na entite https://github.com/…ctEntity.php#…
• eventy na repository/modelu: https://github.com/…pository.php#…, https://github.com/…el/Model.php#L20

@Paradiso toto bohuzel neni uplne nejlip zatim vyresno. Chybe je to vcelku logicka: Kniha nemuze bez autora existovat, tzn. proto pri odstranovani autora to rve, ze je setujes NULL. Resenim je bud rucne predtim ji odstranit, nebo knize povolit, ze nema autora, nepo pouzit rekurzivni mazani s druhym parametrem remove($entity, TRUE); ktery smaze i to, co nemuze bez aktualni entity existovat. V dalsi (asi major) verzi nextras orm bude implementovano neco podobneho jako v doctrine, ze u kazde vazby nastavis si rucne cascadu :)

Promin, byl jsem vcera unaveny a malo cetl. Kdyz koukam na tvuj kod, myslim, ze si mozna nevyzkousel tu spravnou moznost:

$this->orm->productImages->remove($image);
$this->orm->productImages->flush();
// nebo
$this->orm->productImages->removeAndFlush($image);

Melo by to byt pokryte testy, tak doufam, ze to pomuze :)

Ahoj, řeším problém s ukládáním hesla a jeho neustálým přehashováním.
Mám entitu User a vytvořil jsem si setter, který provede hashování hesla.

Problém je v tom, že i když provádím update jedné property (změna property + persistAndFlush), provede se update nad všemi sloupečky.

Když si vydumpuju Entitu, tak tam vidím pole modified, které je ale stále prázdné.
Kód jsem ještě nestudoval, ale čekal bych, že při setu se provede kontrola, tam se zjistí, jestli se property mění, a pokud ne, tak ji neupdatuji.

Proto bych chtěl poprosit o info, jak danou situaci řešit, nebo jestli je jedná o bug.

<?php

namespace App\Model;

use Nette;
use Nette\Security\Passwords;
use Nextras\Orm\Entity\Entity;

/**
 * @property string 	$firstName
 * @property string 	$lastName
 * @property string 	$username
 * @property string 	$password
 * @property string 	$email
 * @property int 		$active {enum self::STATE_*} {default self::STATE_ACTIVE}
 * @property DateTime 	$registeredSince {default now}
 */
class User extends Entity
{
	const STATE_ACTIVE = 1,
		  STATE_NOT_ACTIVE = 0;

	protected function setterPassword($password)
    {
        return Passwords::hash($password);
    }
}
?>

Imo toto nepatri vubec do entity, hashovani by melo byt ve vlastni servisni vrstve.

Máš pravdu, toto není odpovědnost Entity.

Když si vydumpuju Entitu, tak tam vidím pole modified, které je ale stále prázdné.

K čemu slouží toto pole?

Díky

Ahoj,

zrovna se pokouším rozjet testovací prostředí na wedosu a hází mi to zvlášťní chybu.

Compile Error
Cannot redeclare class Nextras\Dbal\InvalidArgumentException

Když smažu ty definice tříd a přesunu ConnectionException pod DriverException, tak se to rozjede.
Resp. spadne to na jinou chybu (nelze se připojit k MySQL pomocí socketu /tmp/mysql.sock).

Nesetkal se s tím někdo?

Zde je výstup z laděnky.

Díky, to pomohlo.

Mám problém s vazbou m:n. Postupuju podle http://nextras.org/…elationships

<?php

namespace App\Model;

use Nette;
use Nextras\Orm\Entity\Entity;

/**
 * @property string 					$name
 * @property string|NULL 				$alias
 * @property string 					$amountUnit {enum self::AMOUNT_UNIT_*} {default self::AMOUNT_UNIT_GRAM}
 * @property int 						$amountDefault
 * @property string 					$priceUnit {enum self::PRICE_UNIT_*} {default self::PRICE_UNIT_CZK}
 * @property int 						$priceDefault
 * @property int 						$type {enum self::TYPE_*}
 * @property int 						$deleted {enum self::STATE_*} {default self::STATE_NOT_DELETED}
 * @property User 						$user {m:1 User}
 * @property ManyHasMany|FoodAlergen[] 	$foodAlergens {m:n FoodAlergen primary}
 */
class Dish extends Entity
{
	const STATE_DELETED = 1,
		  STATE_NOT_DELETED = 0;

	const TYPE_MAIN_DISH = 1,
		  TYPE_SIDE_DISH = 2,
		  TYPE_SOUP = 3;

	const AMOUNT_UNIT_PIECE = 'ks',
		  AMOUNT_UNIT_GRAM = 'g',
		  AMOUNT_UNIT_KILOGRAM = 'kg',
		  AMOUNT_UNIT_MIL = 'ml';

	const PRICE_UNIT_CZK = 'Kč';
}

<?php

namespace App\Model;

use Nette;
use Nextras\Orm\Entity\Entity;

/**
 * @property string 				$name
 * @property string 				$description
 * @property int					$number
 * @property int 					$deleted {enum self::STATE_*} {default self::STATE_NOT_DELETED}
 * @property ManyHasMany|Dish[] 	$dishes {m:n Dish}
 */
class FoodAlergen extends Entity
{
	const STATE_DELETED = 1,
		  STATE_NOT_DELETED = 0;
}

<?php
namespace App\Model;

use Nextras;

/**
 * @property-read FoodAlergensRepository $foodAlergens
 * @property-read DishesRepository $dishes
 * @property-read UsersRepository $users
 */
class Orm extends Nextras\Orm\Model\Model
{

}

public function update($id, $name, $alias, $amountDefault, $amountUnit, $priceDefault, $priceUnit, $type, array $foodAlergenIds)
	{
		$dish = $this->orm->dishes->getById($id);

		$foodAlergens = [];

		foreach($foodAlergenIds as $foodAlergenId)
		{
			$foodAlergens[] = $this->orm->foodAlergens->getById($foodAlergenId);
		}

		$dish->name = $name;
		$dish->alias = $alias;
		$dish->amountDefault = $amountDefault;
		$dish->amountUnit = $amountUnit;
		$dish->priceDefault = $priceDefault;
		$dish->priceUnit = $priceUnit;
		$dish->type = $type;

		\Tracy\Debugger::dump($dish->foodAlergens);
		exit;

		$dish->foodAlergens->set($foodAlergens);

		$this->orm->dishes->persistAndFlush($dish);
	}

Výstup je

array (1)
	0 => 34

Smazal jsem i cache, zkoušel jsem přidávat k Entitám i

use App\Model\FoodAlergensRepository;
use App\Model\DishesRepository;

Nedaří se mi ale načíst si alergeny jako entity, načítá se mi jen jejich ID.

@hologos co vim, tak si tu napsal odpovedel, editoval a pak smazal. Proc? Jinam tim usem to urcite neni. Proc to nefunguje netusim, strasne malo info. A testy by na to mely byt, takze spis nejaka anomalie? =-O videl jsem v tvem postu, ze si neco nejak psatne priradil, to uz neplatí?

Ahoj,

fungoval jsem na Nextras\Orm ver 1.0. Nyní jsem updatnul na master a nestačím se divit. Pryč skloňování, povinné cílové properties v definici vztahů, povinná definice názvu entity, ukecanější primary… mohl bych vědět k čemu to je? Nemyslím to ironicky, naopak, jsem vděčný za toto super ORM, ovšem zajímalo by mě prakticky k čemu to vede… je to rychlejší? Přehlednější? Proč bych neměl zůstat u v1.0 ?

Díky

Jinak, nedoporucuju pouzivat master pro bezne projekty. Ve v1.1 postupne davam fixy :) To doporucju pro produkci :)

Ahoj,
popravdě si vůbec nevím rady s tímto – mám tabulku invoices, která mimo jiné obsahuje sloupce created_by a edited_by, oba jsou klíč na tabulku users. A teď otázka, vůbec nevím jak tohle nadefinovat v entitách daných tabulek, je to vůbec možné?

Díky za radu

Díky za nápovědu, moje definice:

<?php
/**
 * Invoice
 * @property string $number
 * @property int $proforma
 * @property string|NULL $proformaNumber
 * @property Contractor $contractor {m:1 ContractorsRepository}
 * @property Header $header {m:1 HeadersRepository}
 * @property Purpose $purpose {m:1 PurposesRepository}
 * @property DateTime $dueDate
 * @property int $sum
 * @property string $note
 * @property Country|NULL $country {m:1 CountriesRepository}
 *
 * @property User $createdBy {m:1 User::$createdInvoices}
 * @property User $editedBy  {m:1 User::$editedInvoices}
 */
class Invoice extends Entity
{

}
?>

<?php
/**
 * User
 * @property string $email
 * @property string $password
 * @property string $firstName
 * @property string $lastName
 * @property int $active
 *
 * @property Invoice[] $createdInvoices {1:m InvoicesRepository}
 * @property Invoice[] $editedInvoices {1:m InvoicesRepository}
 */
class User extends Entity
{

}
?>

ale bohužel dostávám chybu

<?php
App\Orm\Invoice::$createdBy relationship with App\Orm\User::$createdInvoices is not symetric.
?>

přitom ostatní propojení fungují bez problémů.

Děkuji za nakopnutí

Používám verzi 1.1, ale každopádně po přidání $reversePropertyName na obě strany již vše funguje.

Děkuji moc za nakopnutí.

Ahoj,
ještě jedna (asi hloupá) otázka. Potřebuji ve where použít LIKE. Podle toho co jsem našel v dokumenti findBy() toto nepodporuje a budu muset využít mapper. Znamená to ale, že si budu muset napsat celý dotaz, včetně joinů, nebo mohu pouze nějak připojit where část (něco jako v případě addSelect()?

díky

@hrach asi jsem se špatně vyjádřil :(

Pokud použiji Tvoje řešení, mohu filtrovat pouze ze sloupců v dané tabulce – tedy pokud půjde o InvoicesMapper není problém použít $builder->andWhere('note LIKE ...');.

Jenže co kdybych chtěl něco ve smyslu $builder->andWhere('users.email LIKE ...'); – ačkoliv ORM ví, jak jsou tabulky propojené, nepřišel jsem na správný způsob zapisu.

Kdyz mam m:1, napriklad address a user.

Jak pridavat nove adresy je mi jasne.

$user->addresses->add(new Address);

Mazat take.

$user->addresses->remove($id = 5);

Ale kdyz mam 1 adresu a chci ji editovat a pak ulozit. Zatim to delam takto.

$address = $user->addresses->get()->fetch();
$addresses->persistAndFlush($address);

Ale neslo by to i takto? Pripadne pres nejakou metodu update?

$address = $user->addresses->get()->fetch();
$address->email = 'foo@bar.cz';
$users->persistAndFlush($user);

// ?

$user->addresses->update($address);
$users->persistAndFlush($user);

Diky za odpoved. @hrach

@hrach Ač ve fázi prvotního testování, děsně se tímhle „lehkým“ ORM bavím a jsem Ti za to vděčen. Už jsem chtěl zvedat ruce ve vítězoslavném gestu (jako že mám dotestováno a pojede se naostro), ale ukázalo se, že by to byl jásot poněkud předčasný. Povedlo se mi totiž hned na rozjezdu narazit na nečekaný jev: v testu jsou všechny vazby entit definované jako 1:m, první dva foreach cykly proběhnou přesně podle předpokladu, další (vnořené) sice vygenerují sql v očekávatelné podobě, ale pokládají při každém dalším průchodu stejný dotaz znovu.

Zúčastněný kód je na gistu, použil jsem master, 1.1 se ovšem chová v tomhle případě úplně stejně. Zatím jsem skálopevně přesvědčený, že jsem v tom nevinně, ale třeba mne někdo vyvede z omylu; pro jistotu jsem tedy ještě nezakládal issue.

Díky, zdar a sílu!