Just another programmer's blog

When you serialize doctrine entity and later unserialize you all lazy loaded associations are gone. Initializers won't fetch the data from database as well. One approach could be eagerly fetch all the associations you will need after deserialization. But there is another and more easy and memory effective way. You can do merge() on your entity to "restore" it. But you need to merge each entity you plan to use that could be quite annoying and sometimes impossible. So save your efforts and use recursive merging function above: <?php use Doctrine\ORM\EntityManager; class RecursiveMerge { /** * @var EntityManager */ protected $em; public function __construct ( EntityManager $entityManager ) { $this -> em = $entityManager ; } /** * Merge entity recursively * * @param object $entity * @param int $depth recursion depth to avoid cyclic references issue * * @return object ...

Sometimes you encounter some issue or would like to add some feature to the open source package you use in your project. And it useful enough to be contributed to the original package. Or you fixed some bug and want to share it with package maintainer. The best way (and usually the only way) to do this is to fork the package on github and send the pull request. But what if your application can't work without this fix?  The simplest way to resolve this matter is to move package from vendor to your project and maintain it there. But this approach has a few flaws - it is quite hard to keep library up to date with original and not so easy to contribute to the package. It is much better to fork the package, switch composer to your fork, fix the bug and contribute it back on github. So the steps are: Fork the package on github Just go to the package github page and press button "Fork". As a result you will have a copy of the original package in your account, like a...

Developers that use Doctrine are often puzzled on what should they use for SELECT queries - DQL or SQL? Short answer: both. Long answer: Official Doctrine documentation here says: A common mistake for beginners is to mistake DQL for being just some form of SQL and therefore trying to use table names and column names or join arbitrary tables together in a query. You need to think about DQL as a query language for your object model, not for your relational schema. That page clearly tells us: don't use DQL to built complicated and heavy queries. But what about database independent code? Query building? You might ask... For former question Doctrine has whole  DBAL layer located in  Doctrine\DBAL namespace, for latter it has  Doctrine\DBAL\Query\QueryBuilder which builds pure SQL code in similar way as  Doctrine\ORM\QueryBuilder builds DQL and A LOT! of developers don't even aware of its existence! $qb = $this -> connection ->createQueryBuilder(); $qb...