@ToBeReplaced opened this Issue on November 11th 2014

Piwik makes use of the IGNORE clause in ALTER TABLE, which has been removed as of MySQL 5.7.

There may be other incompatibilities between piwik and MySQL 5.7. The deprecated and removed features can be found at https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html .

See #6623 for how the incompatibilities manifest in a new installation.

@mattab commented on December 1st 2014 Owner

Hi @ToBeReplaced thanks for the suggestion. It sounds quite important to support Mysql 5.7 as soon it will roll in production in many places.

@mattab commented on April 7th 2015 Owner

In saying to the community "Piwik supports Mysql 5.7" we should run our automated test suites on Mysql 5.7 in CI

@johsin18 commented on May 25th 2015

Would be great to fix this ASAP. Usually you don't have control over the MySQL version your provider uses. And the Piwik system check does not even complain, so it's hard to find this problem.

@mattab commented on May 25th 2015 Owner

@johsin18 did you notice any issue on Mysql 5.7 so far?

@johsin18 commented on May 26th 2015

Well, yeah, the actual problem is stated in issue #6623. Effectively, no visits are recorded at all after a fresh install.

@mattab commented on May 27th 2015 Owner

@johsin18 Good point, if we don't make Piwik compatible with Mysql 5.7, Piwik may fail without users knowing why which would be confusing and possibly frustrating. Adding to Short term and hopefully we can make progress on this

@Ramoonus commented on October 25th 2015

bump

@mattab commented on November 24th 2015 Owner

From the MySQL Documentation:

MySQL 5.7.5 and later enforces a maximum length on lock names of 64 characters. Previously, no limit was enforced

The typical string generated by Piwik for this purposes is 65 characters in length. It typically looks like this:

deletePreviousArchiveStatus.piwik_archive_numeric_2015_10.1267863

The get_lock() function is invoked from two functions within core/db.php. The two functions are getDbLock and releaseDbLock. For purposes of expediency on our systems, I wrapped the string used by these functions into a call to md5(), guaranteeing 32 characters at most, and almost ensuring uniqueness. I hope the devs come up with something better.

      if ($db->fetchOne($sql, array(md5($lockName))) == '1') {

These two functions are in turn invoked via acquireArchiveTableLock and releaseArchiveTableLock, both in DataAccess/Model.php.

@otheus commented on November 24th 2015

@mattab Look, I don't want to step on any toes here, but marking 9131 as a "duplicate" of this one seems to only contribute to confusion in the short- and long-run, especially since that bug isn't specifically referenced by this issue, yet is now marked as "closed". In the dev environments I've been in, these would be marked as related, or assigned the same tag ("mysql 5.7.5"). To the extreme counterexample, you could have an "issue" named "fix all bugs" and mark everything as a duplicate of it. ;) And as noted, some of these issues have already been fixed downstream, but not the one in 9131. So it seems wise to keep separate bugs as ... separate.

@mattab commented on November 25th 2015 Owner

, especially since that bug isn't specifically referenced by this issue, yet is now marked as "closed"

the bug is referenced in my comment above + it appears in this page linked above. there is a small risk we would forget to look at #9131 but I trust whoever works on this will not miss it :+1: although, for sure it would work well to leave other issue opened too

@otheus commented on December 9th 2015

I believe you missed my main point. These are separate issues. Marking it as "duplicate" is confusing and erroneous. For instance, existing installations that upgrade to MySQL 5.7.5 will work with the patch I present in #9131. If you want to create an "umbrella" issue, that's perfectly reasonable; but if you close the underlying issues as duplicates, it (1) makes the collective issue harder to attack; developers will try to pick off seemingly easier smaller problems than one, monolithic harder one; (2) makes this particular problem open-ended, since more issues may come to light after the known ones are uncovered, (3) is harder to track which individual issues still need resolving.

Also: FWIW, this is the wrong "place" for this discussion: I just don't know of an alternative. The forums perhaps?

@tsteur commented on December 9th 2015 Owner

I'm getting a bit confused by the duplicates as well and not sure what is to be done here. Finding it easier too to have separate issues for specific things. There's no advantage to me by merging issues into one big issue.

Is it like a general issue to install 5.7.5+ and to run all the tests?

@mattab commented on December 10th 2015 Owner

Ok, re-opened the other one for now.

Is it like a general issue to install 5.7.5+ and to run all the tests?

sounds good :+1:

Later on we could run all tests on 5.7.5 and maybe could create an issue for it

@tsteur commented on December 14th 2015 Owner

I issued two pull requests for other existing issues: https://github.com/piwik/piwik/pull/9383 and https://github.com/piwik/piwik/pull/9382

Apart from that I couldn't find any problems with MySQL 5.7 (mysql Ver 14.14 Distrib 5.7.9). I ran integration and system tests on my local instance. There were some system test failures but I think they are not related to MySQL 5.7. I also tried an installation + some simple tracking and it worked. I guess it's better to just see if any other error occurs and then have a look at the specific error when something comes up.

I'd suggest to close this issue

@mattab commented on December 18th 2015 Owner

Well done @tsteur :+1:

This Issue was closed on December 18th 2015
Powered by GitHub Issue Mirror