Doctrine pro Nette 3.0, nejnovější verze Kdyby/Doctrine není kompatibilní

Osobně používám buď výše zmíněné nettrine/orm, ale stále častěji nepoužívám nic a ty tři servisy potřebné pro vytvoření EntityManageru si prostě zaregistruju do DIčka v configu sám a nejsem tak závislej na ničím balíčku.

To bude asi tím, že nettrine/dbal vyžaduje jen nette/di 2.4, i když ta hláška composeru vůbec k tomu nesedí…

Poslal jsem PR: https://github.com/…dbal/pull/29

Kdybys to potřeboval akutně, tak stačí udělat jako workaround tohle v composeru:

{
	"repositories": [
		{
			"type": "vcs",
			"url": "https://github.com/MartkCz/dbal"
		}
	],
	"require": {
		"nettrine/orm": "dev-master",
		"nettrine/dbal": "dev-master as 0.3.0"
	}
}

Editoval Martk (5. 4. 2019 10:22)

Ahoj, tak se mi povedlo problém téměř vyřešit a rád bych zde publikoval možné řešení pro ostatní.

TL;DR: Pokud můžete zůstat u Nette 2.4, ještě počkejte. Pokud přejdete na Nette 3.0, nefunguje SmartObject v entitách.

Získat instanci EntityManageru je skutečně jednoduché, jak už psal @Mysteria. Dá se to jednoduše udělat třeba takto:

class EntityManager implements EntityManagerInterface
{

	/**
	 * @var Connection
	 */
	private $connection;

	/**
	 * @var Configuration
	 */
	private $configuration;

	/**
	 * @var EventManager
	 */
	private $eventManager;

	/**
	 * @param Connection $connection
	 * @param Configuration $configuration
	 * @param EventManager $eventManager
	 */
	public function __construct(Connection $connection, Configuration $configuration, EventManager $eventManager)
	{
		$this->connection = $connection;
		$this->configuration = $configuration;
		$this->eventManager = $eventManager;
	}

	/**
	 * @return \Doctrine\ORM\EntityManager
	 */
	private function em(): \Doctrine\ORM\EntityManager
	{
		static $cache;

		if ($cache === null) {
			try {
				$cache = \Doctrine\ORM\EntityManager::create(
					$this->connection,
					$this->configuration,
					$this->eventManager
				);
			} catch (ORMException $e) {
				Debugger::log($e);
				trigger_error($e->getMessage(), E_ERROR);
			}
		}

		return $cache;
	}

Nebo seskládat závislosti v Neonu pomocí zavináčových anotací: https://doc.nette.org/…onfiguration#…

Problém je však ještě v samotné Doctrine, a to ten, že ProxyGenerator tvoří proxy třídy bez typehintů, takže nejsou kompatibilní s původní entitou, která obsahje SmartObject (opravdu doporučuji všude používat, řeší geniálně miliony věcí).

V Doctrine jsem na to založil samostatnou issue: https://github.com/…n/issues/868

A snažím se problém vyřešit: https://github.com/…mon/pull/869, ale podle množství připomínek to spíše vidím tak, že balík forknu a vykašlu se na dokončení oprav a počkám na někoho jiného, protože už takhle to zabralo 10 hodin práce a připomínky nemají konce a nevidím to s nějakým rozumným termínem moc reálně.

Díky.

Editoval baraja (11. 4. 2019 9:31)

@Felix máme v teamu část juniorů, kteří občas dělají chyby. SmartObject za nás řeší dohledání, že třeba nenastavují neexistující property.

Dále SmartObject řeší podporu starých šablon, kdy se k metodě přistupuje jako k property. Vím, že by se to tak nemělo dělat, ale realita je v praxi jiná.

Dává ti to takto smysl?

Editoval baraja (11. 4. 2019 10:57)

Ahoj,

trochu mě mrzí, že toto téma zůstalo bez reakce a finálního řešení, jak Doctrine do Nette 3.0 elegantně vložit.

Rozhodl jsem se proto publikovat moje řešení veřejně, které používám na svých projektech. Veřejné řešení je hodně ořezané, aby nemělo zbytečné závislosti a je zaměřeno na maximální výkon.

Budu moc rád, pokud ho otestujete i na vašem projektu: https://github.com/…ore/doctrine

Pár informací:

• Dokumentace plně v angličtině, důležité metody popsané přímo v doc bloku
• Je závislý na symfony/console a contributte/console
• Část implementace vychází z Nettrine, ale dávalo mi smysl implementaci vylepšit a vydat tak, jak je vydáno nyní
• Implementuji vlastní EntityManager, který se automaticky nastavuje přes extension včetně řady best-practice pro zvýšení výkonu a správné nastavení cachování
• Na Kdyby balíku se mi líbilo, že šlo příkaz pro generování struktury tabulek volat rovnou nad www/index.php, tak jsem tuto funkčnost jednoduše zachoval. Generuje to jenom v CLI režimu shutdown metodu do DIC, takže to je velice šetrné k systémovým prostředkům a nebrzdí requesty
• Hezký Tracy panel na steroidech pro výpis položených dotazů včetně možnosti sledování jejich druhů a rychlostí. U pomalých dotazů podbarvuje návěští barevně + na začátku panelu ukazuje hezký přehled timeline s vyhodnocováním dotazů po sobě
• Automaticky obsahuje entitu generující tabulku core__database_slow_query pro logování pomalých dotazů s možností zpětného sledování, kde aplikace nejvíc trpí (vím, že to umí MySql taky, ale toto je víc elegantní a nemusí se nic nastavovat)
• Užitečné helper metody pro pokročilou práci s entitami (mapování z jedné na druhou, zjištění závislostí, dědičností, druhů, …). Používá se k tomu vlastnost discriminatoru, kterou jsem popsal před chvilkou na Wikipedii: https://cs.wikipedia.org/…iscriminator

Budu moc rád za všechny tipy a zlepšení. Opravu anglické gramatiky provedu brzy, protože zatím jsem limitován znalostmi. Bugy obratem opravím, stačí založit issue.

Díky.

@Felix máš pravdu a plánuji přispívat i do Nettrine.

Jenom u všech public balíků řeším problém s tím, že obsluhuji klienty, kteří potřebují nasazovat řešení co nejdřív a už včera bylo často pozdě.

Pokud tedy narazím na nějakou fatální chybu v balíku (řeším stovky use-casů každý den), tak potřebuji provést rychlou opravu a pak ideálně co nejdřív vydat verzi a postupně strojově aktualizovat všechny produkční projekty, kde by šla chyba zneužít.

Narazil jsem na fatální chyby i přímo v samotné Doctrine, kde jsem se snažil chyby opravit a poslat PR, ale po 50 komentářích v rámci jedné issue a 5 denní buzeraci jsem se na to raději vykašlal. Konkrétní příklad: https://github.com/…mon/pull/869

Chápu, že kód v balíku musí být „dokonalý“ – nicméně člověk často potřebuje vydávat a hotfixovat rychle, protože na balíku běží produkční weby velkých firem, které dnes a denně používáš a není možné opravu nevydat ještě ten stejný den.

Pojďme se tedy domluvit tak, že do Nettrine implementuji co nejvíc funkcí budu moci a zároveň budou dávat smysl, nicméně i tak bych rád zachoval v existenci balík, který řeší nějaké další scénáře, které se do stabilního balíku nevešly, protože jsou už jenom z principu dost „tricky“. Příklad je třeba tato užitečná servisa, kterou potřebuji úplně na každém e-shopu, kde pracuji s produkty, které potřebují řešit závislosti mezi sebou a přemapování typů entit: https://github.com/…neHelper.php, a ano, přemapování je v řadě případů pořád lepší řešení, než cokoli jiného.

Dává ti to takto smysl?