Enable prevention of delete queries #7544

New Issue

admin · 2026-01-22T15:53:11+01:00

admin commented

2026-01-22 15:53:11 +01:00

Originally created by @janopae on GitHub (Aug 26, 2025).

Feature Request

What

I'd like to see a way to prevent a QueryBuilder instance to be turned into a delete query builder later on.

Currently, when you call $queryBuilder->select() on a QueryBuilder and return it, another actory might call ->delete() and overwrite the type set previously.

Why

PostDelete and PreDelete events do not get fired on delete queries. Therefore, depending on your model, delete queries might be a serious theat to your data consistency. While it is pretty common to enforce the rule that only Repository classes may create query builders for certain entities (using their createQueryBuilder method) among a team, it is pretty common for other classes to add additional constraints to the QueryBuilder.

Programmers unaware of the details of the model (e. g. the creator of the model themselves in the future) might acidentally create a delete query and bypass the safety shield of the Repository and cause serious damage to the data consistency through this.

How

One way would be to throw an exception when changing the type of the QueryBuilder after the explicit use of select. However, this would be a breaking change.

Alternatively, we could implement a new method, called something like onlyAllowSelect, that causes any other action that tries to change the QueryBuilder type to throw an exception.

Originally created by @janopae on GitHub (Aug 26, 2025). ### Feature Request #### What I'd like to see a way to prevent a QueryBuilder instance to be turned into a delete query builder later on. Currently, when you call `$queryBuilder->select()` on a QueryBuilder and return it, another actory might call `->delete()` and overwrite the `type` set previously. #### Why `PostDelete` and `PreDelete` events do not get fired on delete queries. Therefore, depending on your model, delete queries might be a serious theat to your data consistency. While it is pretty common to enforce the rule that only Repository classes may create query builders for certain entities (using their `createQueryBuilder` method) among a team, it is pretty common for other classes to add additional constraints to the QueryBuilder. Programmers unaware of the details of the model (e. g. the creator of the model themselves in the future) might acidentally create a `delete` query and bypass the safety shield of the Repository and cause serious damage to the data consistency through this. #### How One way would be to throw an exception when changing the type of the QueryBuilder after the explicit use of `select`. However, this would be a breaking change. Alternatively, we could implement a new method, called something like `onlyAllowSelect`, that causes any other action that tries to change the QueryBuilder type to throw an exception.

admin referenced this issue

2026-01-22 16:07:52 +01:00

[PR #7544] Fix collection matching for many to many associations #10533

Sign in to join this conversation.