Ability to alter QueryBuilder before SQL generation and execution (SQLFilter but with DQL) #7542

Open
opened 2026-01-22 15:53:11 +01:00 by admin · 0 comments
Owner

Originally created by @Cafeine42 on GitHub (Aug 14, 2025).

Feature Request

What

Add a mechanism (such as an event or an extension point) that allows developers to intercept and modify a QueryBuilder before it is transformed into SQL and executed. This would provide a way to apply filters or additional constraints using the QueryBuilder API instead of raw SQL.

Why

Doctrine’s existing SQLFilter feature is useful for simple filters but requires writing raw SQL directly.
For complex filters, such as those involving subqueries, multiple joins, or dynamic conditional logic, writing raw SQL becomes verbose, repetitive, and harder to maintain. Being able to work at the QueryBuilder level would make filters more expressive, reusable, and easier to test while preserving the benefits of Doctrine’s abstraction layer.

How

Introduce a new event (for example, onQueryBuilderReady) or an extension interface that triggers after the QueryBuilder is built but before SQL generation. Listeners could then modify the QueryBuilder using Doctrine’s fluent API:

class MyQueryBuilderFilterListener
{
    public function onQueryBuilderReady(QueryBuilder $qb)
    {
        $qb->andWhere('EXISTS (
            SELECT 1 FROM related_entity re
            WHERE re.foreign_id = main.id
            AND re.status = :status
        )')
        ->setParameter('status', 'active');
    }
}

This would allow implementing complex query modifications without resorting to raw SQL.

Originally created by @Cafeine42 on GitHub (Aug 14, 2025). ### Feature Request #### What Add a mechanism (such as an event or an extension point) that allows developers to intercept and modify a QueryBuilder before it is transformed into SQL and executed. This would provide a way to apply filters or additional constraints using the QueryBuilder API instead of raw SQL. #### Why Doctrine’s existing SQLFilter feature is useful for simple filters but requires writing raw SQL directly. For complex filters, such as those involving subqueries, multiple joins, or dynamic conditional logic, writing raw SQL becomes verbose, repetitive, and harder to maintain. Being able to work at the QueryBuilder level would make filters more expressive, reusable, and easier to test while preserving the benefits of Doctrine’s abstraction layer. #### How Introduce a new event (for example, onQueryBuilderReady) or an extension interface that triggers after the QueryBuilder is built but before SQL generation. Listeners could then modify the QueryBuilder using Doctrine’s fluent API: ```php class MyQueryBuilderFilterListener { public function onQueryBuilderReady(QueryBuilder $qb) { $qb->andWhere('EXISTS ( SELECT 1 FROM related_entity re WHERE re.foreign_id = main.id AND re.status = :status )') ->setParameter('status', 'active'); } } ``` This would allow implementing complex query modifications without resorting to raw SQL.
admin added the New Feature label 2026-01-22 15:53:11 +01:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7542