Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The batch API should be a pluggable service so it could be swapped out or mocked for testing.
The following will need to be completed:
- #2959723: Create an interface and initial class for the batch processor service
- Migrate the existing functionality into the new service class. This will be a few different tickets.
- Change the code in core to use the service instead of calling the current functions. This will be a few different tickets.
#1797526: Make batch a wrapper around the queue system
Done:
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | Implement_batch_service-2875151-3.patch | 33.03 KB | John Cook |
Issue fork drupal-2875151
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #3
John Cook CreditAttribution: John Cook at Creode commentedThe patch listed here builds on the work done in #2401797: Introduce a batch builder class to make the batch API easier to use, and as such will need the code from that issue's patch to be applied first until it is committed.
I've added an interface for the
BatchQueueControllerto implement and added it to thecore.services.ymlfile asbatch.processor.Also, I've changed the function calls in
batch.incandform.incto use the new service. We would still need to deprecate the existing functions in favour of the service, but I think we should do that in a different issue.I'm leaving the issue as "active" until #2401797 is committed.
Comment #4
John Cook CreditAttribution: John Cook at Creode commentedDear Committer,
Please ensure that the following people are credited:
They worked on #2320469: Move batch processing to a service, which is a duplicate of this issue and #2401797: Introduce a batch builder class to make the batch API easier to use. I used code from their work to provide the initial patch for this issue.
For reference the commit message is:
Comment #6
John Cook CreditAttribution: John Cook at Creode commentedComment #7
John Cook CreditAttribution: John Cook at Creode commentedI've updated the summary and turned this issue into a plan as implementing batch processing as a service will be split into many tasks.
Comment #9
colanLooks like that's in now.
Comment #12
nickolajComment #13
alex_optimComment #14
nickolajComment #15
sarathkmThis module in sandbox works fine. May be implementing this module fundamentals as base in core will be great starting point.
https://www.drupal.org/sandbox/acrosman/3025562
Comment #16
daffie CreditAttribution: daffie commentedComment #17
jibranComment #18
geek-merlinCan we please clarify how this relates to #1797526: Make batch a wrapper around the queue system
Comment #19
volegerThis looks more like a meta issue. And also great plan how to deprecate a bunch oh functions from includes files (#2999721: [META] Deprecate the legacy include files before Drupal 9). Updated IS.
Comment #21
sokru CreditAttribution: sokru as a volunteer commentedRemoved "Needs reroll" tag, because most of the code is changes to non-existing file
core/lib/Drupal/Core/Batch/BatchQueueController.php.Comment #22
daffie CreditAttribution: daffie commented@sokru: The patch does not apply any more, therefore the patch needs to be rerolled.
Comment #23
eelkeblokSince this is a Plan, does it even make sense to have a patch? I think it is a great idea, although how to implement this would need some careful consideration.
@geek-merlin, as you imply, there is a considerable amount of overlap with #1797526: Make batch a wrapper around the queue system, although the core aspect of that ticket (make batches a wrapper around the queue system) has since actually been implemented, leaving #1797526: Make batch a wrapper around the queue system a rebel without a cause, basically. I do believe there are some good ideas in there to improve the batch system in general. Probably those ideas (without going through the issue again, I can only come up with the one Chx implemented, although there may be more) should be outlined here to get a complete overview.
One aspect of redesigning the batch system I have been struggling with is this. Various core systems make use of the batch system. When a new batch system is introduced, the old batch API would be deprecated and at some point those mechanisms (the one that has been central to my thoughts about this is user cancellation) would have to be converted to the new system. However, at least the user cancellation API relies on how the current batch system works; it is possible to add to the batch built by the user cancellation system when hook_user_cancel is called by making use of the current Batch API. So, when user cancellation would start making use of an entirely new Batch API, that would be a BC-breaking change. That would mean that the new system can't really be that radically different from what it is now; it would need to essentially be a different wrapper around the same mechanics to allow the old Batch API to still work with any batches created with the new API. Is there any prior art for this sort of situation? Do we need to first abstract away such dependencies before we can make work of the batch API?
Comment #24
firewaller CreditAttribution: firewaller commented+1