Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
database system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
23 Jan 2026 at 07:54 UTC
Updated:
16 Jul 2026 at 09:55 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
mondrakeComment #4
mondrakeComment #5
smustgrave commentedFirst thought was this seems like something that should be removed in 13 if deprecated now and boom you already had that!
I did a search for truncate( and got 23 instances in 19 files and the MR addressed them all
Seems like a good deprecation to me.
Comment #6
catchIt's not clear to me why we need a new method and can't change the return value of the current method.
Comment #7
mondrake#6 @catch because in the new method (yes the name is debatable, naming things is hard) I suggest to add a
voidnative return type to make it clear that there is no returned value from the call. We cannot addvoidtoexecutebecause it is inherited from Drupal\Core\Database\Query\Query, and its other implementations do have a return value (in phpdoc at least for the moment). If we narrow tovoid, then we would force the parent to the impossible task of supporting both void and a concrete return value: https://php.watch/versions/8.0/union-types#:~:text=The%20void%20type%20i....Comment #8
sivaji_ganesh_jojodae commentedMerge conflicts must be resolved.
Comment #9
sivaji_ganesh_jojodae commentedMerge conflicts has been resolved.
Comment #10
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #11
mondrakeComment #12
smustgrave commentedSeems like a good deprecation, CR reads fine.
Comment #13
alexpottHang on. I think #6 needs more discussion. Why can't the return type of Drupal\Core\Database\Query\Query be documented correctly. Having to call a different method to execute a query depending on the what the query is doing feels like bad API. I think there are other options one of which is leaving the API docs as they are and returning NULL from truncate because the amount of rows are unknowable.
Comment #14
mondrakeOr, we could introduce two interfaces
QueryExecutionReturningRecordsetInterface, withprotected function execute(): StatementInterface;QueryExecutionVoidInterface, withprotected function execute(): void;the first to be implemented by the Select base class, the other by the Truncate base class (and ideally in the future by DML statements where we should not expect a value). That would be type strict which would be a win IMHO.
Comment #16
mondrakeFunnily, I found out that Query::execute() is not API at the moment... the abstract class is setting it protected!
Then each DB operation base class extends its visibility to public.
Only
SelectInterfaceis having it as an API.MR!16067 is doing #14 only for
Truncate.Comment #17
mondrakeComment #18
mondrakeComment #20
daffie commentedAll code changes look good to me.
The IS and CR are in order.
The only problem could be that there is no testing added. I leave it up to the committer if this is necessary.
For me it is RTBC.
Comment #21
catchThe changes look good here, but the change record is very out of date with the MR now. Should we just mention the new interface?
Comment #22
mondrakeEdited the CR.
Comment #25
catchCommitted/pushed to main and 11.x, thanks!