Exception caused by MySQL 5.6 gtid replication

Hm. After upgrade to php 8.1 and MariaDB 10.5 #17 starts to give WSOD. Have no time to investigate, so just reverted it. Keep it in mind.

james.williams → credited marco → .

A performance issue was reported, with a patch, at ✨ Increase performance when exporting many rows Closed: duplicate , saying:

When trying to export many rows (10000+), even using a batch, the first step may take several seconds.
In some environments this may result in a timeout.

On closer inspection, the patch works on the code being introduced in this issue. So I think that's a report suggesting more work is needed here? I've taken a guess that an updated patch combining the patch from ✨ Increase performance when exporting many rows Closed: duplicate is all that's needed, but someone else will need to test this. I haven't included an interdiff, because that patch from that other issue is is the interdiff when compared to the patch from comment 27 on this ticket.

Thanks for the patch everyone, and @james.williams thanks for adding in the work from ✨ Increase performance when exporting many rows Closed: duplicate .

It's great that it's working for a number of people on this issue, it shows that the approach has promise.

However, as it stands I think the patch in #31 will introduce a fundamental regression:

At the moment the creation of the table and the insertion of the data is an atomic operation performed entirely by the database.

With this patch, we first create the table, and then we SELECT all the data and get it into the PHP process, and then we INSERT it back into our temporary table.
This might cause memory issues in PHP or as ✨ Increase performance when exporting many rows Closed: duplicate outlined, performance issue with shuffling all that data between the database and PHP and back to the database.

I suspect that the approach can be re-worked slightly, so that:

1. The temporary table is created
2. An INSERT...FROM SELECT query is built up, and that can be sent to the database.
3. We'll get a quicker copy, with less memory usage all around.

(I assume that gtid replication can handle INSERT...FROM SELECT queries, if not, then urgh. We should check that assumption!)

Sorry for the lack of attention to your issue, please accept my apologies.

Drupal 7 is going to be end-of-life'd by the community in approximately 1 month. →

As such, I am closing all non-critical looking, non-PHP compatibility issues for Views Data Export to tidy up the issue queues and reduce the noise. You can read about this on #3492246: Close down Drupal 7 issues.

If you feel like this issue has been closed by mistake, please do comment about re-opening it.
If you feel like the ticket is still relevant for the 8.x-1.x version of the module, then please search for a duplicate issue first, and if there really isn't one (and you've looked properly) then change the version on the ticket and re-open.

Thanks to everyone involved in this issue: for reporting it, and moving it along, it is truly appreciated.
The Drupal community wouldn't be what it is today without your involvement and effort, so I'm sorry that we couldn't get this issue resolved. Hopefully we'll work together in a future issue though, and get that one resolved :)