The version string is strange because my MariaDB 10.1.40 doesn't include the 5.5.5 version.

Can you update to a higher 10.1.x version?

Also Joomla 4 will support MySQL 5.6+ only, but that will no prevent us from thinking about supporting MariaDB.

I am using XAMPP which MySQL came pre-installed.
The install was working as of yesterday so a commit today must have affected this.
I will see if I can update to the latest version.

The database layer has been updated today.

Someone needs to fix the language string to deal with the 5.5.3 message.

joomla-framework/database@b71d7a7 changed the driver code requirements.

The driver code has never had logic to specially parse MariaDB version strings. If this is going to become an issue, someone needs to write (with tests because this is going to be a borderline flaky behavior IMO) some code to try and differentiate MariaDB versions from MySQL versions.

PR #25246 for language strings.

Does MariaDB qualify as MySQL 5.6?

MariaDB 10.0 is based on MySQL 5.5 including features of MySQL 5.6.

At the moment we discuss MariaDB Support (or not breaking it) in PLT hopefully we have conclusion and solution soon.

Any input on this is welcome.

Upgraded to the latest version of XAMPP.

You need MySQL 5.6 or higher to continue the installation. Your version is: 5.5.5-10.3.15-MariaDB

Doctrine does some post parsing for MySQLi connections to try and handle this case, see this method for details. Maybe something similar can be applied (but again, as I said this really should include tests in the Framework repo). They don't do this for PDO connections though, and I'm not about to take the time to find out if it's intentional or an oversight (or if this is something PDO itself deals with).

I would also only suggest adding this change on Framework 2.0 and not including it in a Framework 1.x or CMS 3.x release because adding that type of behavior is going to be a B/C break for anyone who is trying to parse the version data themselves (as it looks like the return would go from 5.5.5-10.3.15-MariaDB to 10.3.15).

(And in all honesty, if the B/C break in the version parsing gets accepted then a isMariaDBConnection() method might need to be added to the MySQL drivers otherwise the one way someone could actually identify the platform outside the database API is most likely lost without hacky Reflection uses, not that that's a bad thing as at a minimum that would let the stats plugin and API be updated to more easily distinguish MariaDB and MySQL users, as an example use of such an API feature in core).

There is no reason to bring this into Framework 1.x that version isn't used in j4 or did I miss somthing?

We only use the 2.0 and there is the question whats the best way to do it. Creating an own "empty" driver that extends mysql or try to abstract mariadb difference into mysql driver? (sound not like a good option).

It seams doctrine does it for the pdo driver in the abstractmysqldriver https://github.com/doctrine/dbal/blob/91f01420e1eaf6cf746ba45ccd3880a571946c32/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php#L172-L194

I have no idea what happens to mariadb and mysql in the future but iirc the json implementation differs. So this could lead to a problem if we simple check version > 5.6 for mariadb because its already 10.4...

There is no reason to bring this into Framework 1.x that version isn't used in j4 or did I miss somthing?

Nope, but pointing out changing the methods that return the version string on MySQL drivers is a B/C break for anyone calling JDatabaseDriver::getVersion() and expecting to be able to parse out the MariaDB specific bit, hence the reason I explicitly said of the three versions of database code available (what's currently in Joomla 3.x, and the two Framework version branches) that only one should be patched if so decided, unless you're going to subclass the PDO MySQL and MySQLi drivers for MariaDB (basically the same way SQL Azure is a subclass of SQL Server which only changes the name property). Subclassing IMO only has benefits if the driver and query code are going to be more smart about MariaDB specific features.

Ok thx yeah the getVersion shouldn't change in the 1.x version.

The subclass is the question, that really depends if mariadb will really do stuff that we want to use and is not implemented the same way as mysql. I hope such thing will not be needed... I will check mariadb combat documentation maybe @alikon can help on this.

https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/

Looks as if certain MariaDB versions are binary compatible with corresponding MySQL vewrsion, see link above. Only for views there seem to be some incompatibility, but we don't use views in Joomla DBs.

IMO a subclass isn't necessary; Joomla's driver and query classes don't expose anything that would have behavioral differences between the original and the fork. Even looking at where Doctrine has dedicated code paths for MariaDB support, it is predominantly around JSON type support, the list of reserved keywords, or escape sequences for default values (none of which have an equivalent thing in the Joomla API). If the core database driver API started becoming aware of the JSON column type, maybe you could make an argument for subclasses, but for right now I'd say IF someone were to introduce a behavioral change in the API it be to change the return of getVersion() if using MariaDB and add a isMariaDBConnection() that could be used on MySQL drivers. MAYBE add a minimum supported version for MariaDB in parallel with the MySQL minimum (otherwise right now the code basically assumes anything that has a MySQL-ish compatible version string works, and with that 5.5.5- prefix and the MySQL 5.6 minimum requirement that isn't the case).

So I think we should do something similar to doctrine and don't use a subclass for now only add the version check and the isMariaDBConnection function as michael suggested.

We have production meeting tomorrow and will talk about it, I think minimum version should be mariadb 10.0 because we have? the same problem for mysql 5.7 with datetime columns and converting them. On the other site mariadb 10.0 support ended in March 2019.

I have no idea if our migration path for mysql 5.7 works for mariadb we should check this carefully.

@HLeithner Any news from the production meeting?

We discussed it but didn't come to a conclusion because we need more information about our installation base. It seams that MariaDB has about 30% usage. The main question at the moment is the difference in json support between MariaDB and MySQL.

A snapshot of the discussion is that we like to support MariaDB but don't know exactly which version and how we handle it in the driver. Also the upgrade problem like MySQL 5.5 and 5.7 have to be checked if this problem also exists in MariaDB 5.5 and MariaDB 10.1

At least detecting MariaDB similar to doctrine as Michael noted should be done soon. Without this we can't install Joomla! 4 on MariaDB.

If I remember correctly if using $mysqli->server_info then you need to be careful as the returned strings are different on Linux ("10.0.17-MariaDB-log") and Windows ("5.5.5-10.0.17-MariaDB-log")

could be a starting point https://github.com/doctrine/dbal/blob/90f79c8b39fa451264537440ead0fe1ab1c751b8/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php#L173

Yes, and the regex handles what Brian mentioned above, as far as I understand it.

At least detecting MariaDB similar to doctrine as Michael noted should be done soon. Without this we can't install Joomla! 4 on MariaDB.

I will start to work on that if nobody else says he/she is doing that already.

please, go for it... you have my green light, whatever this means

Because of utf8mb4 checks, the MySQLi driver of the framework includes at several places checks against hard-coded MySQL server versions, which are below the minimum requirement for J 4.0-dev / Framework database 2.0-dev. So it needs to clean this up a bit, too. So be patient.

I have a question to all: If the minimum requirement for MySQL is 5.6 in J4, does this apply only to the DB on which J4 is installed, or does it also apply to any external other MySQL DB to which any 3rd party extension can connect, using our DB driver?

I ask because the 2.0-dev branch of the framework package still contains checks for utf8mb4 compatibility with hard-coded version numbers older than the requirements, and if we want to keep that and do the same with MariaDB with same purpose (but other version numbers of course) because we want to support connections to old DBs, then it would result in ugly code when just modifying the MySQLi db driver, which makes me think we might better make a subclass like with the sqlazure and the sqlserver.

But if we don't have to connect to old DBs, we can drop most of that utf8mb4 stuff. A subclass still mght make sense then, but code would be much nicer in any case without the utf8mb4 version checks.

Another question: Would it be sufficient to check if MariaDB only on connection and store the result in a static protected var, like it is with the utf8mb4 flag in the mysqli driver? Otherwise we would have to do that with every call of getVersion.

Maybe we should subclass anyway, because minimum version number currently is saved in a static var, which is directly used with getVersion and version_compare for the checks at different places, and making a condition like "if mariadb check this minimum version and if not then check the other one" at all these places will not really be nice code. In addition it might be necessary to set session variables differently for MariaDB, which also speaks for a subclass.

Or maybe we should rewite all that version check stuff to have the version string which we have now just for information purpose and use a sanitized string ("major.minor.patch" always at the beginning, leading "5.5.5-" stripped off if MariaDB, similar to the doctrine code linked above) for the version_compare?

I am thankful for every input I can get from you, guys, before I go wrong ways.

Maybe I was thinking too complicated ... easy first draft solution is in progress.

Leave the utf8mb4 checks alone, they aren't hurting anything right now (it's basically dead code for checking server compatibility, but the client compatibility parts are still necessary).

@mbabker Yes, I agree. And it seems we are lucky and in J4 the installer lib already uses the right way to check the minimum versio, so nothing to to in core beside fetching framework database package.

I have meanwhile a proposal which seems not to break anything with MySQL. Would need a tester with MariaDB (=> @Quy ) and a good code reviewer (= you, Michael):

joomla-framework/database#166.

@Quy Ah, just right now I see how my previous comment reads. Sorry, of course you are an excellent reviewer, too, and I would like you to review. Now I'll have a family visit, and after that I will see what happened.

@Quy And for test, do you also have a younger MariaDB version than the one posted in the description of this issue? I have set the minimum required to 10.2 in the framework PR. If not, I have to lower that and we can later after test increase it again. Or you change that variable locally when testing.

Sorry I do not. Now I upgraded to the latest version which is 10.3.15.

I have set the minimum required to 10.2 in the framework PR. If not, I have to lower that and we can later after test increase it again.

Set it to 10.0 right now and leave it be. If that's going to get raised, there's a bit more effort involved to clean up a lot of Travis builds there that actually run the MySQL test cases against a MariaDB server.

@Quy PR for J4 is PR #25285 . Please test.