About the Query Container

Edit on GitHub
When to use query containers

Don’t use query containers to cross module boundaries, as this increases modules coupling. However, you can use them behind Repository and Entity Manager as query aggregations. Previously, query containers were used to cross module borders (via dependency providers), which led to higher module coupling and leaking of persistence layer from one domain object to another, and therefore, to higher maintenance efforts and lower code reusability. This approach has been deprecated now, so we don’t recommend using query containers like this in your project development.

A query container holds all the database queries of the current module.

Each module has exactly one query container, which also acts as an entry point to the persistence layer. Internally, it uses query objects and returns unterminated queries.

As you can see in the example below, the query container consists of query-methods which gets query objects from the factory, adds some filters or joins and returns the unterminated query object.

Unterminated queries should be avoided in the Application Layers above Persistence. Consider using the Repository and Entity Manager patterns to decouple persistence and ORM implementation details.

Unterminated means you don’t execute the query with find(), findOne() or count().

use Spryker\Zed\Kernel\Persistence\AbstractQueryContainer;

 * @method \Pyz\Zed\MyBundle\Persistence\MyBundlePersistenceFactory getFactory()
class MyBundleQueryContainer extends AbstractQueryContainer implements MyBundleQueryContainerInterface
    public function queryTemplateByPath($path)
        $query = $this->getFactory()->createTemplateQuery();

        return $query;

You might use the following definitions to generate the related code:

  • vendor/bin/console spryk:run AddZedPersistencePropelAbstractQuery - Add Zed Persistence Propel Abstract Query

See the Spryk documentation for details.

What’s next?