[RFC] Check for minimum supported database type and version

[zero-24]

Reason / Problem

In Joomla 4.0 there is the plan to remove support for mssql and bump the requirment versions for postgres and mysql

Expected result

If you are on 3.x and an unspported database type or version you should get a message (similiar to the PHP Version) and you can't install the update

Actual result

You can install the update without any warning and after the update your site is broken.

Why now?

Becuase how the update component is designed we need to implement the checks before they can be checked. So we need to implement them into 3.x befor 4.0 is released. And all updates need to first update to the version where we have implemented the checks to be sure they don't crash the sites.

But anyway which version this will be implemented we should implement a soulution to prevert future problems with 4.0 😄

More technical.

Sadly the updater code ignore as of today subtags in the update server definition so this don't work:

<minimum_database>
    <databse servertype="mysql" version="5.5.3" />
    <databse servertype="postgres" version="9.2" />
</minimum_database>

RFC proposals

As we can't use the nice way we need to try it different one idea could be:

<supported_database>mysql,postgres</supported_database>
<minimum_mysql>5.5.3</minimum_mysql>
<minimum_postgres>9.2</minimum_postgres>

As i think we should not hard implement the databases we need two tags one that hold the list of supported database types and than per databasetype the version.

Another idea:

<supported_databases servertypes="mysql,postgres" mysql="5.5.3" postgres="9.2" />

<supported_databases servertypes="mysql,postgres" versions="5.5.3,9.2" />

Before I try to implemt something like that I would be happy on feedback and maybe help and/or other ideas on that topic.

[mbabker]

I'd rather we stop using the extension update system to handle core updates because the rules for core updates are NOT the same as the rules for extension updates and frankly the only reason it's been doing this for so long is because the 1.6 team got cheap and implemented Joomla as an extension of itself. Use WordPress' updater as an example for what I'd rather core do in the future (take essentially the same data the stats server is collecting minus the unique identifier hash as it isn't storing downstream data in any form, send it to a similar server, and have that server respond with whatever the CMS can update itself to).

Part of the problem with this is every time we add additional checks for the update system, they first have to be implemented into the core API in a way that the updater classes can parse and turn into something useful for this process, then we have to impose limitations on what versions can see what updates. To update 3.0.0 to 4.0.0 using only the update stuff in core today you have to update to 3.2.2+ to get the PHP minimum check, then to whatever release is going to have these checks, THEN 4.0.

[zero-24]

So what do you think we can do? Before we rewrite com_joomlaupdate in 4.0 (or any later version)?

[mbabker]

Unfortunately for 3.x we're going to have to add this XML junk as it's the only way we have of handling it right now. As part of 4.0 I would suggest looking at implementing my rant above for the reasons I said above. It will be MUCH easier to change or add additional checks to a remote server than it is to implement the corresponding changes in the application and have the app rely on itself to figure out what to do with that data.

[zero-24]

Any suggestion which version we should use or do you have no preference on the proposed XML's?

[mbabker]

Since we already screwed up and don't have a parent <platform> tag (which would be perfect for PHP, database, etc. checks), I would suggest this schema:

<database>
    <mysql>5.5.3</mysql>
    <postgresql>9.2.0</postgresql>
</database>

It's XML, it should be easy to read. The database engine tags I used in that example would be the result of JFactory::getDbo()->getServerType() (so instead of having one tag for each of the MySQL drivers, there's only one in total). Your supported_databases tag to me is too error prone as is; it doesn't have any sort of associations and basically requires someone to order their elements correctly and with a very explicit syntax (so if I put a space in my stuff it'd probably break things or if I screwed up and listed MySQL then PostgreSQL but put the versions in reverse).

The other acceptable alternative would be this:

<supported_databases mysql="5.5.3" postgresql="9.2" />

Where again the database engines and versions are explicitly listed together.

[zero-24]

Thanks. I will try to implement the first one.

[zero-24]

ok here is a POC (I'm going to test that later). That implements the seccond acceptable alternative you can take a look if you want (WIP):
https://github.com/joomla/joomla-cms/compare/staging...zero-24:database_minimum?expand=1

The problem with with fist one is that it result in $this->currentUpdate->mysql and than you need to predefine all supported server servertypes to get the values and that is bad. ;)

[mbabker]

Sounds like a bad construct honestly. You should be able to have $this->currentUpdate->database and that have all of the objects, then it's simple $this->currentUpdate->database->mysql type checks.

Either way it just goes to show that our XML constructs and parsers suck.

[zero-24]

Thanks! I'm going to setup some testing now and later than the PR if everything works like it should.

[zero-24]

Closing as there is the PR. #12355

@mbabker Do you have a list of inconsistencies in the Joomla Code? You can add another one. ...

In the extension update the attributes of an XML tag are an array like

$this->currentUpdate->supported_databases[strtoupper(JFactory::getDbo()->getServerType())];

In the code for the Joomla Update it self you have the same infos as stdClass:
$this->currentUpdate->supported_databases->strtolower(JFactory::getDbo()->getServerType());

😄 Ah did you notice also strtolower & strtoupper ... 😃

[mbabker]

I'd be the reason OSM filed for bankruptcy if I billed them for my therapist visits after all the years of dealing with things like that.

[zero-24]

hehe :)