We created a new new fork

[back-2-95]

Our fork is here https://github.com/druidfi/mysqldump-php and can be used with Composer as it's also in Packagist.

We have now first stable release there: 1.0.0

Background

• We love this library and we use it for GDPR-related activities around databases for our customers
• We have 2 other libraries which use this (and which are also forks)
• https://github.com/druidfi/gdpr-mysqldump which uses mysqldump-php and adds GDPR-functionality: anonymize, clean etc.
• https://github.com/druidfi/drush-gdpr-dumper which uses ^^ to create Drush CLI command for Drupal 9 projects we use quite a lot

What we did

• As we see that there was not much activity for ~2 years, we decided to fork the library and basically have somekind of continuity for our projects - so out toolset can be even installed when other constraints are going forward
• We wanna have everything running on supported PHP versions so that was first thing to do
• We broke the classes to their own files and did much type castings, codestyle fixes and cleanup

All the changes can be seen here as a draft PR: #253

TODO

• We need to figure out what test.sh and test.php should be doing so those could be updated. We can already run them locally and in Github Actions but don't understand the results < I'd really like some insight here ❤️ ✅
• Maybe drop sqlite support - cannot see much task about it here? ✅
• Later this year, drop support for PHP 7 and add support for PHP 8.2
• Going through PRs in this repo to see if there is something to include

Any comments, ideas or general feedback would be appreciated :heart:

[ifsnop]

• We need to figure out what test.sh and test.php should be doing so those could be updated. We can already run them locally and in Github Actions but don't understand the results < I'd really like some insight here ❤️

The idea behind test.sh is to compare outputs from mysqldump and mysqldump-php. There are several tests with different options (blobs, hex, extended inserts). Every PR that affect the output got the corresponding test.

Of all the changes to the code, I would ask not to drop support for older versions of PHP. There is no gain and lots to be lost. Lots of hosting sites still use PHP 5, and are the most that need a tool like mysqldump-php.

Hosting servers with PHP 7 already include tools to perform backups to S3 buckets etc

Regards,

[back-2-95]

@ifsnop thanks for the input!

I need to go through the test.sh with thought. Current output of tests are like this: https://gist.github.com/back-2-95/ccd2fcba79afba937ad2fcd7b991297d - Maybe you could shortly comment on the output?

For the EOL PHP support: I think anyone in that scenario should just keep using this library as it does the job great. Please don't deprecate this library or something like that. 😄 I have seen similar case of multiple alternative versions of the same functionality being created e.g. for supporting Symfony 4-5 and Symfony 6+ (because PHP support).

Our need or more like requirement to keep all within supported versions is just so strict we needed to act on that. Also I could say that in our scenarios we don't use any traditional hosting and we constantly update our components.

I'm not totally sure what you mean with PHP 7+tools+S3 ?

And if I could still pick your brain about supporting different databases (than mysq/mariadb): Was there some concrete ideas why? From the code I can see sqlite somewhat tried but those others had no code. For me mysqldump already points heavily on the mysql/mariadb but I can see utilizing PDO offers the possibility.

[back-2-95]

@ifsnop I updated the gist in previous comment ^^ more verbose output but the same diffs remain.

They seem to be related to double typed fields. I could not find old travis test outputs so I'm not sure what is the issue. Is it my setup, or Mysql versions being too new or what.

[ifsnop]

@ifsnop https://github.com/ifsnop thanks for the input!

I need to go through the test.sh with thought. Current output of tests are like this: https://gist.github.com/back-2-95/ccd2fcba79afba937ad2fcd7b991297d - Maybe you could shortly comment on the output?

Looks like there are different decimal numbers between mysqldump and mysqldump-php.

Direct output from the database should be checked, to see which one is right. Also, one output uses e as the exponentiation while the other uses E.

As an easy fix, you could just update the output to generate a new set of tests.

[ifsnop]

And if I could still pick your brain about supporting different databases (than mysq/mariadb): Was there some concrete ideas why? From the code I can see sqlite somewhat tried but those others had no code. For me mysqldump already points heavily on the mysql/mariadb but I can see utilizing PDO offers the possibility.

Originally, mysqldump-php supported several databases, including postfix and sqlite. Then, PDO library was used, postfix support removed, but some patches for sqlite where included.

I no longer test sqlite compatibility, and sqlite users are probably non existent. So all the code related to multiple database engines support can be removed. I didn't do it since the net gain is small.

.Message ID: @.***>

[back-2-95]

Ok, I digged in with you suggestions:

• database gets populated correctly with source sql (the double field's value)
• PHP (pdo) returns it wrong BUT only with PHP 8.1
• If running tests with PHP 7.4 or PHP 8.0, they pass

[ifsnop]

I've been reading changelog from PHP 8.1 and it has no info about double/pdo/mysql changes, so maybe it's a bug. I'll try to do some tests.

• PHP (pdo) returns it wrong BUT only with PHP 8.1
• If running tests with PHP 7.4 or PHP 8.0, they pass

[garas]

PHP 8.1:

Integers and floats in result sets will now be returned using native PHP types instead of strings when using emulated prepared statements. This matches the behavior of native prepared statements. The previous behaviour can be restored by enabling the PDO::ATTR_STRINGIFY_FETCHES option.

https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.pdo

-1.7976931348623157e308 is string from MySQL. -1.7976931348623E+308 is PHP float when converted to string.

[back-2-95]

@ifsnop I already tried that PDO::ATTR_STRINGIFY_FETCHES for PDO connection (pdo options) without success.

[garas]

Did you use $this->pdoOptions in constructor or $this->conn->setAttribute()?

https://github.com/druidfi/mysqldump-php/blob/bd3d8c44a2275eba1367177107dcdd8585045cd2/src/Mysqldump.php#L278-L285

[back-2-95]

@garas I tried it with setAttribute. And now also with pdoOptions of the constructor. Still the same.

[back-2-95]

Now my test matrix reflects current situation: https://github.com/druidfi/mysqldump-php/actions/runs/2911009428

[back-2-95]

We have now internally tested this with Alpine, Debian and Ubuntu images and in all of them PHP 8.1 fails with that double value. We have tried to change, add, remove various PDO options mentioned but no success there.

[back-2-95]

I added extra pdo_checks file to do clean pdo call before starting mysqldump-php processing: https://github.com/druidfi/mysqldump-php/runs/7973950319?check_suite_focus=true

[back-2-95]

I created following "fix" to overcome the issue: https://github.com/druidfi/mysqldump-php/pull/8

It passes all the tests now.

[back-2-95]

All tests now pass with PHP 8.2 official images/runners