PHPackages igdr/doctrine-specification - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Database & ORM](/categories/database) 4. / 5. igdr/doctrine-specification ActiveLibrary[Database & ORM](/categories/database) igdr/doctrine-specification =========================== Specification Pattern for your Doctrine repositories v0.10.0(7y ago)23471MITPHPPHP >=7.1 Since Feb 20Pushed 7y ago4 watchersCompare [ Source](https://github.com/igdr/doctrine-specification)[ Packagist](https://packagist.org/packages/igdr/doctrine-specification)[ RSS](/packages/igdr-doctrine-specification/feed)WikiDiscussions master Synced 1mo ago READMEChangelogDependencies (2)Versions (22)Used By (0) Doctrine Specification ====================== [](#doctrine-specification) This library gives you a new way for writing queries. Using the \[Specification pattern\]\[wiki\_spec\_pattern\] you will get small Specification classes that are highly reusable. The problem with writing Doctrine queries is that it soon will be messy. When your application grows you will have 20+ function in your Doctrine repositories. All with long and complicated QueryBuilder calls. You will also find that you are using a lot of parameters to the same method to accommodate different use cases. After a discussion with Kacper Gunia on \[Sound of Symfony podcast\]\[sos\] about how to test your Doctrine repositories properly, we (Kacper and Tobias) decided to create this library. We have been inspired by Benjamin Eberlei's thoughts in his \[blog post\]\[whitewashing\]. ### Table of contents [](#table-of-contents) 1. [Motivation](#why-do-we-need-this-lib) and [basic understanding](#the-practical-differences) (this page) 2. \[Usage examples\]\[doc-usage\] 3. \[Create your own spec\]\[doc-create\] 4. \[Contributing to the library\]\[contributing\] Why do we need this lib? ------------------------ [](#why-do-we-need-this-lib) You are probably wondering why we created this library. Your entity repositories are working just fine as they are, right? But if your friend open one of your repository classes he/she would probably find that the code is not as perfect as you thought. Entity repositories have a tendency to get messy. Problems may include: - Too many functions (`findActiveUser`, `findActiveUserWithPicture`, `findUserToEmail`, etc) - Some functions have too many arguments - Code duplication - Difficult to test Requirements of the solution ---------------------------- [](#requirements-of-the-solution) The solution should have the following features: - Easy to test - Easy to extend, store and run - Re-usable code - Single responsibility principle - Hides the implementation details of the ORM. (This might seen like nitpicking, however it leads to bloated client code doing the query builder work over and over again.) The practical differences ------------------------- [](#the-practical-differences) This is an example of how you use the lib. Say that you want to fetch some Adverts and close them. We should select all Adverts that have their `endDate` in the past. If `endDate` is null make it 4 weeks after the `startDate`. ``` // Not using the lib $qb = $this->em->getRepository('User') ->createQueryBuilder('r'); return $qb->where('r.ended = 0') ->andWhere( $qb->expr()->orX( 'r.endDate < :now', $qb->expr()->andX( 'r.endDate IS NULL', 'r.startDate < :timeLimit' ) ) ) ->setParameter('now', new \DateTime()) ->setParameter('timeLimit', new \DateTime('-4weeks')) ->getQuery() ->getResult(); ``` ``` use Igdr\DoctrineSpecification\Specification; // Using the lib $spec = Specification::expr()->andX( Specification::expr()->eq('ended', 0), Specification::expr()->orX( Specification::expr()->lt('endDate', new \DateTime()), Specification::expr()->andX( Specification::expr()->isNull('endDate'), Specification::expr()->lt('startDate', new \DateTime('-4weeks')) ) ) ); return $this->em->getRepository('RecruitmentBundle:Advert')->match($spec); ``` Yes, it looks pretty much the same. But the later is reusable. Say you want another query to fetch Adverts that we should close but only for a specific company. #### Doctrine Specification [](#doctrine-specification-1) ``` /** * Class AdvertsWeShouldCloseSpecification */ class AdvertsWeShouldCloseSpecification extends Specification { /** * {@inheritdoc} */ public static function create() { return new self(); } /** * @param ExpressionInterface $spec * * @return $this */ public function applyWhere(ExpressionInterface $spec) { $this->andWhere($spec); return $this; } /** * @param \DateTime $startDate * * @return $this */ public function applyTimeFilter(\DateTime $startDate) { $spec = self::expr()->andX( self::expr()->eq('ended', 0), self::expr()->orX( self::expr()->lt('endDate'), self::expr()->andX( self::expr()->isNull('endDate'), self::expr()->lt('startDate', $startDate) ) ) ); $this->andWhere($spec); return $this; } } $spec = AdvertsWeShouldCloseSpecification::create()->applyTimeFilter(new \DateTime('-4weeks')); return $this->em->getRepository('RecruitmentBundle:Advert')->match($spec); ``` #### QueryBuilder [](#querybuilder) If you were about to do the same thing with only the QueryBuilder it would look like this: ``` class AdvertRepository extends EntitySpecificationRepository { protected function filterAdvertsWeShouldClose($qb) { return $qb ->andWhere('r.ended = 0') ->andWhere( $qb->expr()->orX( 'r.endDate < :now', $qb->expr()->andX('r.endDate IS NULL', 'r.startDate < :timeLimit') ) ) ->setParameter('now', new \DateTime()) ->setParameter('timeLimit', new \DateTime('-4weeks')) ; } protected function filterOwnedByCompany($qb, Company $company) { return $qb ->join('company', 'c') ->andWhere('c.id = :company_id') ->setParameter('company_id', $company->getId()) ; } public function myQuery(Company $company) { $qb = $this->em->getRepository('RecruitmentBundle:Advert')->createQueryBuilder('r'); $this->filterAdvertsWeShouldClose($qb) $this->filterOwnedByCompany($qb, $company) return $qb->getQuery()->getResult(); } } ``` Configuration ============= [](#configuration) Edit your doctrine settings to register default repository ``` orm: default_repository_class: Igdr\DoctrineSpecification\EntitySpecificationRepository auto_generate_proxy_classes: "%kernel.debug%" naming_strategy: doctrine.orm.naming_strategy.underscore auto_mapping: true ``` The issues with the QueryBuilder implementation are: - You may only use the filters `filterOwnedByCompany` and `filterAdvertsWeShouldClose` inside AdvertRepository. - You can not build a tree with And/Or/Not. Say that you want every Advert but not those owned by $company. There is no way to reuse `filterOwnedByCompany()` in that case. - Different parts of the QueryBuilder filtering cannot be composed together, because of the way the API is created. Assume we have a filterGroupsForApi() call, there is no way to combine it with another call filterGroupsForPermissions(). Instead reusing this code will lead to a third method filterGroupsForApiAndPermissions(). ### Health Score 29 — LowBetter than 60% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity16 Limited adoption so far Community12 Small or concentrated contributor base Maturity57 Maturing project, gaining track record Bus Factor1 Top contributor holds 95% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~25 days Recently: every ~104 days Total 21 Last Release 2866d ago PHP version history (2 changes)v0.9PHP >=7.0 v0.9.4PHP >=7.1 ### Community Maintainers ![](https://www.gravatar.com/avatar/3b43bdf609a0bbcb50ca6e968cd7a62159b63c2296c1151b937a87cf78f29890?d=identicon)[igdr](/maintainers/igdr) --- Top Contributors [![igdr](https://avatars.githubusercontent.com/u/4249152?v=4)](https://github.com/igdr "igdr (19 commits)")[![atrigub](https://avatars.githubusercontent.com/u/389271?v=4)](https://github.com/atrigub "atrigub (1 commits)") --- Tags specificationdoctrinerepositorycriteria ### Embed Badge ![Health badge](/badges/igdr-doctrine-specification/health.svg) ``` [![Health](https://phpackages.com/badges/igdr-doctrine-specification/health.svg)](https://phpackages.com/packages/igdr-doctrine-specification) ``` ### Alternatives [happyr/doctrine-specification Specification Pattern for your Doctrine repositories 452915.0k8](/packages/happyr-doctrine-specification)[kphoen/rulerz Powerful implementation of the Specification pattern 8831.3M6](/packages/kphoen-rulerz)[rikbruil/doctrine-specification Doctrine Specification pattern for building queries dynamically and with re-usable classes for composition. 50251.6k2](/packages/rikbruil-doctrine-specification)[mediagone/doctrine-specifications Doctrine implementation of repository Specifications pattern 353.8k3](/packages/mediagone-doctrine-specifications) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)