Kdyby/Doctrine – ako na to?

Třeba takto:

		// Get all available user emails
		$messages = $this->messagesSearching->findAllByUserInFolder($this->userEntity, $this->folderEntity);

		if ( $messages instanceof \Kdyby\Doctrine\ResultSet) {
			// Get messages paginator
			$paginator = $this['paginator']->getPaginator();
			// Set max items per page
			$paginator->itemsPerPage = $this->itemsPerPage;

			$messages = $messages
				->applySorting(array('m.created DESC'))
				->applyPaginator($paginator)
				->getIterator(\Doctrine\ORM\AbstractQuery::HYDRATE_OBJECT);

		} else {
			// Store info message
			$this->flashMessage("mailbox.emails.messages.addressCouldNotBeLoaded", "warning");

			throw new BadRequestException;
		}

kde search funkce je cca takto:

	public function findAllByUserInFolder(IUser $user, IFolder $folder)
	{
		return $this->dao->fetch(new FindMessagesByUserInFolderQuery($user, $folder));
	}

a využívá querybuilder kdyby:

class FindMessagesByUserInFolderQuery extends \Kdyby\Doctrine\QueryObject
{
	/**
	 * @var IUser
	 */
	private $user;

	/**
	 * @var IFolder
	 */
	private $folder;

	/**
	 * @param IUser $user
	 * @param IFolder $folder
	 */
	function __construct(IUser $user, IFolder $folder)
	{
		$this->user		= $user;
		$this->folder	= $folder;
	}

	/**
	 * @param \Kdyby\Persistence\Queryable $repository
	 *
	 * @return \Doctrine\ORM\Query|\Doctrine\ORM\QueryBuilder
	 */
	protected function doCreateQuery(Kdyby\Persistence\Queryable $repository)
	{
		return $repository->createQueryBuilder()
			->select('m')
			->from(Message::getClassName(), 'm')
			->where('m.user = :user')
			->andWhere('m.folder = :folder')
			->orderBy('m.created', 'DESC')
			->setParameter('user', $this->user)
			->setParameter('folder', $this->folder);
	}
}

to není objekt kvůli paginatoru ale jednoduše mám fasády rozděleny podle typu na:

• NecoFacade – pro práci s konkrétní jednou entitou
• NecoSearching – pro práci se sadou entit, třeba pro načtení sady uživatelů kteří vyhovují konkrétní podmínce atd
• NecoStats – pro zjištování nějakých statistických dat, např. počet uživatelů pro danou podmínku

QueryObject je objekt pro vytváření samotných custom query

co jsem se ti snažil ukázat je jak získáš ResultSet kterému pak stačí předat paginator a on ti vrátí potřebná data.

QueryObjectr je fajn, ale pokud se ti nechce delat na kazdou query dalsi objekt jako me, tka to muzes mit nejak takto:

public function actionDefault(){
	$paginator = $this['categoryPaginator']->getPaginator();
	$this->template->articles = $doctrinePaginator = $this->articleFacade->getArticlesForCategoryPaginator($category, $paginator->getOffset());
	$paginator->setItemCount(count($doctrinePaginator));
}

protected function createComponentCategoryPaginator()
{
	$vp = $this->visualPaginatorFactory->create();
	$vp->getPaginator()->setItemsPerPage(4);
	return $vp;
}

v te fasade samotne potom jenom vratis Doctrine Paginator:

public function getPublishedArticlesPaginator($firstResult, $maxResults = 50)
{
	$qb = $this->articleDao->createQueryBuilder();
....
	$paginator = new Paginator($qb);
	return $paginator;
}

matej21: díky za tip! s tí mto vypadá mnohem hezčeji

Editoval Jiří Nápravník (7. 3. 2014 0:24)

Když se koukneš na api třídy EntityDao, tak zjistíš, že createQueryBuilder má dva argumenty. Tím že tam předáš to „u“, tak se ti tam základní select i from automaticky doplní

/**
 * @return ResultSet
 */
public function findAll()
{
    $qb = $this->usersDao->createQueryBuilder('u')
    return new ResultSet($qb->getQuery());
}

Je taky potřeba připomenout, že Query objekty a ResultSet jsou určené pro data, která chcete vypisovat někde v nějaké šabloně a je jich neurčité množství – kdekoliv nepotřebujete stránkovat, tak píšete Query objekt zbytečně.

ResultSet je také elegantní způsob, jak oddálit vykonání dotazu do databáze až do šablony, kde si výsledek můžete nacachovat makrem. Protože DQL objekt obaluje a neumožňuje jeho další modifikaci (například v presenteru).

Ohledně třídění…

Mějme třeba komponentu FiltersControl, která se nějak vykreslí do šablony, jako jsou třeba filtry pod hlavičkou na damejidlo. A takový control ten má různé persistentní parametry a může klidně obsahovat i formulář. Má metodu getFilters(), která vrací nějaký náš objekt, třeba RestaurantFilters

class RestaurantFilters
{
	public $deliveryPrice = 0;
	public $onlyCardPayment = FALSE;
	// ..
}

ten si v té getFilters() naplním

public function getFilters()
{
	$filters = new RestaurantFilters;
	$filters->deliveryPrice = $this->deliveryPrice;
	// ...
	return $filters;
}

A pak si ho předám třeba v render mětodě, třeba do facade

public function renderDefault()
{
	$this->template->restaurants = $this->restaurantsFacade
		->filter($this['filters']->getFilters());
}

No a ta metoda filter má za úkol poskládat takovou query (nebo několik, je-li to třeba), která vrátí jenom ty restaurace, které odpovídají filtrům. A pokud bych chtěl, tak si můžu vrátit třeba ResultSet a stránkovat si ho.

Co se snažím říct, tak že ResultSet není určen na další filtrování, filtrování je doménová logika kterou bych doporučil dělat v modelu. Zato stránkování, to je věc čistě uživatelského rozhranní a nevidím důvod proč by o tom měl model vůbec něco vědět, že něco takového existuje :)

akadlec: stránkovadlo ve fasádě se mi taky moc nelíbilo. ale ted jsem to v podstatě vyřešil tím resultsetem, který mi fasáda vrací a pagiantor tam šoupnu v presenteru

Filip Procházka: pokud jen vytáhnu data z fasaády a posunu do view, v presenteru s nimi nic nedělám. Je dobý nápad obalit to do ResultSetu? Nebo to jej už spíše zneužívám, pro co určen není?

Krasne, dakujem pekne. Ked mozem mam dalsiu otazku. Do Facade mozem vlozit aj metodu save(), delete()?, alebo sa na to pouziva dalsi objekt?

@duskohu: no můžeš ale tuším sem někde čet že to není příliš košér. Já přešel na entity crud a entity manager (ne manager z doctrine) a tento manager má v sobě tři metody, create/update/remove a dělá to že mu předám parametry v arrayhash (form nebo custom data) a můžu si tam zadefinovat before a after akce, takže třeba při vytvoření nového uživatele tam navážu akci co mě pošle notifikaci že se někdo regnul atd.

@Jiří Nápravník: jako že si do šablony předáš ResultSet a až tam budeš dělat načtení dat?

Editoval akadlec (8. 3. 2014 11:37)

mno pokud sem dobře odsledoval tak i když udělaš select dat tak dokud nezískáš iterátor tak se select nespustí

Tady máš dokumentaci doctrine, nemá žádný význam ji přepisovat po kouskách sem do fóra. Prva si ji přečti pak se ptej dál :)

@Filip Procházka studujem :-)
Napriek tomu robim nieco zle, @akadlec dik takto som to riesil, ale remove mi nefunguje
predpokladal som ze treba zavolat $em->flush(); ktore vola sa vola v Kdyby.Doctrine.EntityDao::save()
cize predpokladam ze to mam urobit takto:

// vytiahnem entitu
$userEntity = $this->usersFacade->getUserDao()->find($id);

// vytvorim rolu
foreach ($this->userEntity->getRoles() as $role) {
	$userEntity->removeRole($role);
}

a kedze Kdyby.Doctrine.EntityDao save() vola flush predpokladam ze zavolam nad entitou save Lenze predane role entity nevymaze, ale nevrati ani error.

$this->usersFacade->save($userEntity);

Takze toto je uz tiez o Doctrine, dik, aspon viem kde mam hladat. Inak na roles mam cascade={„persist“, „remove“}

a ještě doplním pokud chceš flushnout více entit najednou jako sem řešil třeba já když sem provedl změny v entitě usera která má relace na další entity a přes usera sem provedl změny i v nich tak jak radil @Filip Procházka, musíš flushnout celý EM

Caute, tak sa mi uz podarilo skoro vsetko rozbehat. Ale mam v jednej veci este nejasno. Konkretne ide o sorting. Samozrejme viem ze sa to pouziva:

/** @var ResultSet $users */
$users = $this->usersFacade->findFiltered($this->getFilter());
$users->applySorting(array('u.name ASC', 'u.surname ASC'));

Co sa mi nepaci? To ze musim pisat to u.name, u.surname, bez u mi to nejde, a ked v fasade zmenim to u, tak samozrejme to uz vobec. A moja otazka znie, ako riesite sorting, aby to bolo nejak ciste?

Dakujem pani konecne som sa dostal dalej. Teraz som narazil na dalsi problem. Mam QueryBuilder:

		$qb = $this->dao->createQueryBuilder('c')
			->select('c', 'cl', 'm')
			->leftJoin('c.client', 'cl',
				\Doctrine\ORM\Query\Expr\Join::WITH,
				'c.client = cl.id'
			)
			->leftJoin('c.model', 'm',
				\Doctrine\ORM\Query\Expr\Join::WITH,
				'c.model = m.id'
			);

A neviem ako pomocou whereCriteria() postupne nahadzat kombinacie eq a like.

		$whereCriteria = array();

		if ($filter->id !== NULL) {
			$whereCriteria['c.id'] = $filter->id;
		}

		if ($filter->clientName !== NULL) {
			$whereCriteria['cl.name LIKE'] = '%' . $filter->clientName . '%';
		}

		if ($filter->modelName !== NULL) {
			$whereCriteria['m.name LIKE'] = '%' . $filter->modelName . '%';
		}

		$qb->whereCriteria($whereCriteria);
		return new ResultSet($qb->getQuery());

Toto mi vygeneruje:

SELECT c, cl, m
FROM Nas\ServiceModule\Model\Contract c
LEFT JOIN c.client cl WITH c.client = cl.id
LEFT JOIN c.model m WITH c.model = m.id
INNER JOIN c.cl c
INNER JOIN c.m m
WHERE c.id = :param_1 AND c.name LIKE :param_2 AND m.name LIKE :param_3
ORDER BY c.id DESC

a padne to na: applyPaginator()

Kdyby\Doctrine\QueryException

[Semantical Error] line 0, col 156 near 'c INNER JOIN': Error: Class Nas\ServiceModule\Model\Contract has no association named cl

Neviete mi poradit co robim zle?

Editoval duskohu (20. 3. 2014 23:25)

Join::WITH se používá pokud chceš přidat další omezení na filtrování relací přímo v DQL, ale tu základní vazbu kterou máš už přímo v metadatech entity tam psát už nemáš!

Aha, dakujem Join::WITH som dal prec. Ale stale neviem vyriesit tu kombinaciu where like. neviete poradit?

Dakujem velmi pekne, funguje :-), no ten pull request by asi nedopadol dobre :-(, nejako sa este necitim ze mam na to level.

Editoval duskohu (23. 3. 2014 16:06)