Closed emteknetnz closed 1 year ago
I'm encountering this problem as well and it has been affecting my backups. 😅 Hopefully a fix like this with conditional checks gets merged in soon.
It seems to me that making sure if there are errors with the script that a non-zero exit code is returned is also important. Is that something that happens?
From what I experienced yes, but I can double check. I have a script that checks the exit code immediately after, and it would have triggered.
The actual detection looks sensible, we could also detect the version of the db client/server as there should be a clear version info this was introduced for both MySQL and MariaDB. Trying to execute the command and check the return code is also ok, I guess.
Figuring out how to compile/create the phar file using Github CI would also be good since the current one is potentially several (~6) years old, though when installing using the curl method I get the version supporting the TMPDIR modifier which is around 2 years old
Travis was automatically deploying built phars (https://github.com/silverstripe/sspak/blob/master/.travis.yml#L26-L27).
It looks like this may have stopped working - probably because the encypted GH token has expired. Moving this to GH actions shouldn't be any more complex than what is already in the travis config.
Moving this to GH actions shouldn't be any more complex than what is already in the travis config.
Honestly I'd be inclined to just drop support for the multiple ways of being able to install this thing and force the use of composer (I'm assuming that a global install works just as well as a project install). I see no reason to have to maintain extra ways to install this, especially given the history of it silently breaking.
I've backlogged a card for the team to audit where things are at now and look to see if there are any quick wins to salvage the old functionality - though my recommendation is to remove it.
@sabina-talipova I've updated the readme
I'm still getting this error with the latest version 548042a
mysqldump: unknown variable 'column-statistics=0'
My workaround was to manually replace these lines with $columnStatistics = '';
Using MySQL 5.7.40-1.el7
$ mysqldump --user=root --password=test --host=mysql site --column-statistics=0
mysqldump: unknown variable 'column-statistics=0'
$ echo $?
7
Hi @OldStarchy,
It works as was expected. In README we mention about this potential message, please see Notes section here.
This is the result of mysqldump
execution in this line https://github.com/silverstripe/sspak/blob/548042abf5a890963f0240fc7c80acbe65044e9f/src/SSPak.php#L335
It prevents further throwing an error in this line https://github.com/silverstripe/sspak/blob/548042abf5a890963f0240fc7c80acbe65044e9f/src/SSPak.php#L344
Command sspak save
works nice and creates sspak file.
Issue https://github.com/silverstripe/sspak/issues/90