Make non-progressive batch operations possible

sukr_s → changed the visibility of the branch 638712-make-non-progressive-batch to hidden.

sukr_s → changed the visibility of the branch 11.x to hidden.

With this fix progressive value can be set in batch definition. if progressive is false then it run in a single run else it uses multiple run. usage e.g

$operations = ['my operations'];
  $batch = [
    'title' => 'My batch runs in single run',
    'operations' => $operations,
    'progressive' => FALSE,
  ];
  batch_set($batch);
  batch_process();

Bhanu951 → changed the visibility of the branch 11.x to hidden.

Removing tests tag as coverage can be seen here https://git.drupalcode.org/issue/drupal-638712/-/jobs/1645989
Hiding patches since fix is in the MR.

Issue summary appears complete and believe matches the solution.

Only one I'm iffy about is

  $this->drupalGet('admin/reports/dblog');
    $this->assertSession()->pageTextContains('Non progressive operation 100');

If there is just a better way to check the values without having to go to the page but may not be a big deal. Was the only thing I saw.

I read the issue summary, the comments and the MR.

@satbir.singh, thanks for getting this working. To help reviewers, the information in #69 should be in the issue summary in the proposed resolution section. That is the best place for people to find and understand the consequences of the proposed change. Thanks.

In #54 the solution of the patch in #47 was questioned as doing too much work. They then preferred the solution from #41. The solution in the MR is difference again. There should be discussion here on the reason the current solution was chosen over the others.

I am setting back to NW for a comment in the MR and to get agreement on the solution.

batch_set function accepts the batch definition with progressive as a parameter. #41 introduces a new parameter to the batch_process. Having a new parameter in batch_process can cause conflict between the value set when creating the batch with batch_set vis-a-vis calling the batch_process.

The proposed solution uses the value set in the batch definition so that it's consistently available throughout the processing of the batch.

Feedback appears to be addressed here

I think we can make two improvements to the test.

After reviewing batch_test_stack() I applied all my suggestions to the test and marking back to rtbc as my changes are only test changes.

So I think that the key comment by @yched in #12 is largely ignored by the current fix. @yched points out that whether or not the batch is process progressively or not should be an option on the batch processor (using the batch_process() function) and not the batch definition. I think we should change tack here and do one of the options suggested in #12. We should also deprecate \Drupal\Core\Batch\BatchBuilder::setProgressive() as this currently does not work and is incorrect for the reasons suggest in that comment.

My suggestion is that the current fix is commited so it's immediately usable. In addition open a new ticket for implementing the approach suggested in #12 🐛 Make non-progressive batch operations possible RTBC . So setting back to RTBC.

🐛 Refactor Batch API Active has been opened for comment 12

@sukr_s but the point about #12 is that the approach of having progressive-ness set by the batch is incorrect. It is a property of the processor not the batch.

Pinging the framework managers to chime in here because I'm not convinced about the current direction as per #77.

@alexpott I understand that. As per the current design the progressiveness is a part of the batch_set / batch definition. I'm suggesting that we make the current design work as it was designed by fixing the current bug.

The improvement of moving the progressive definition from batch definition to batch_process can be taken up in a new ticket.

#77 makes sense to me and I think captures the original intent

@sukr_s as both @larowlan and I agree going to set this back to needs work. This issue should:
1. Deprecate setting progressive as part of the batch
2. Convert batch_process and _batch_process into a service
3. Add a way to process the batch progressively and non-progressively via the new service.

The reason the API did not work is because it didn't make sense. Making the current change here will cause problems due to

- it will affect the whole processing, so what if set A specifies 'progressive' and batch B specifies 'non progressive' ?

noted. I've closed the other ticket.