[#19361] - Provide a way to install own database driver
- Closed
- 12 Jan 2018
- Medium
- Build: staging
- # 19361
Steps to reproduce the issue
We are writing a simple driver that extends mysqli core driver but implements the deprecated functions from joomla 2.5 to now. In joomla 4 alpha there is no way to install a new database driver without modifying Joomla4 core files.
Even though the database driver is properly created in:
\libraries\vendor\joomla\database\src\Mysqlilegacy\
and it's static::isSupported returns true,
the Joomla global configuration will not load the driver within the option lists because it's not listed within
\administrator\components\com_config\forms\application.xml
<field
name="dbtype"
type="databaseconnection"
label="COM_CONFIG_FIELD_DATABASE_TYPE_LABEL"
supported="mysql,mysqli,pgsql,postgresql"
filter="string" />
thus any installation of a database driver will always require Joomla core modification.
possible solution is to adjust application.xml to:
<field
name="dbtype"
type="databaseconnection"
label="COM_CONFIG_FIELD_DATABASE_TYPE_LABEL"
filter="string" />
in my case since i got a PDO driver for MS SQL i now also see PDO within the list.
allowing to install own database drivers will further enable to use load balacing drivers that connect to various distributed servers.
best regards, stan
joomla-cms-bot
- | Labels |
Added:
?
|
||
Closed for the reasons stated
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-01-12 17:56:46 |
| Closed_By | ⇒ | brianteeman |
Well, why not to adjust "isSupported" from Oracle or SQLLite if it cannot run on CMS ? Instead you limit CMS not to use any 3rd party database drivers.
The main purpose to use legacy driver is to provide:
$db->gerErrorMsg()
$db->query()
and possibly other deprecated functions that otherwise would need to get adjusted within the application.
this is not the point of this report.
yes, it's simple to say that i should adjust my application, but it's current used on 20 000 domains and the code base and number of various plugins is quite large. it would take another few years to get this resolved.
maybe your business plan is based on renewals of incompatible software, but i would really prefer joomla to be considered business oriented and not just feature oriented.
i see absolutely no reason for joomla to loose another 90% of userbase as it did when Joomla 1.5 had renamed many fucntions and thus caused many users to reconsider the CMS to other systems which do not drop classes and functions every 2 or 3 years.
please consider the CMS to be extensible - i.e. adjust the core DB drivers which are not compatible so they do not show up in the com_config instead of CMS itself and re-evaluate the deprecated classes and methods. if php was dropping functions and classes in the rate as joomla is, nobody would be using it any longer.
thank you, stan
The isSupported() method checks if the specific driver is supported on the PHP runtime environment. As I said before, we have drivers in the API which can be used by developers for their tooling but the CMS will not run on (i.e. if you have a need for a CMS extension communicating with an external Oracle database to fetch data, your extension can use our Oracle driver to do so, but the CMS is not supported with an Oracle backend). It is needlessly restrictive of our API to either change the isSupported method to say "this driver is supported by the CMS" or to remove drivers that the CMS can run against.
This is why the databaseconnection field type supports a list of drivers that can be used as an option for that form field. In the case of the CMS, this restricts the list to drivers which our application stack can run on and is fully supported (for 3.x that's MySQL, PostgreSQL, and SQL Server; 4.x removes SQL Server). In the case of an extension which supports database connections other than the primary connection used in the CMS request cycle, they may either further restrict this (i.e. MySQL only) or may use any of the drivers supported by the API.
Other commentary aside, we are not changing the database API in the way you are requesting. There are alternative ways already supported by the API to reach the end state you're looking for. If you really feel the need to introduce drivers maintaining support for APIs which have been deprecated since 2012, then you will need to use other existing APIs to hook the system to add those options (all forms have plugin events dispatched, you can manipulate the form definition through those if you must).
The supported attribute can't be removed. There are drivers that we support in the API but the CMS will not run against (i.e. Oracle or SQLite).
For your use case, I would not try to change the global application to use a totally different database driver. In your custom code, if you need a driver including a legacy layer I would use
DatabaseDriver::getInstance()to do it instead in your local code. Or, less hacky (and something I generally hate suggesting), use a plugin to replace the driver stored inJoomla\CMS\Factory::$database(granted you can't effectively do this until the first system plugin event but you should not need this legacy layer before then otherwise you have most assuredly core hacked).You can also look into using the existing plugin events to manipulate forms allowing the database driver to be selected. Either way I wouldn't suggest a change in core that removes some of the sanity checks to prevent users from setting up a configuration that isn't supported, especially at this level which has global implications.