Sector(s)
This driver allows using Oracle Database as the primary backend for Drupal 10. All the Drupal core tests are passed!
About the project
It was a demand of an upcoming government project to use Oracle with Drupal. All the attempts to persuade clients not to do so have failed. Actually, we still recommend using MySQL instead of Oracle, if possible, but that’s another story.
With that demand in mind, we chose both: to cover the project's needs and to contribute to the community by:
- porting the existing Drupal 7 module to Drupal 10;
- improving it;
- making it possible to install fresh Drupal 8 with the standard (not minimal) installation profile.
We highly recommend using this driver for Oracle integration only, but not as a primary backend. The best scenario is to add Oracle Database as an additional database on Drupal 10 project, which will obtain the ability to use all the power of Drupal Database layer in this case.
List of the most important solved technical problems:
1. Long identifiers. Oracle has a limit of 30 characters for any machine names (tables, field names, indexes, sequences, etc). In its turn, Drupal creates a lot of long identifiers. In Oracle Database 12cR2, the maximum length of most identifiers is now 128 characters, but we still a limit of 30 characters should be handled. Actually, this solution is strictly from Drupal 7 driver version, we just improved and refactored it a bit.
2. Drupal.org composer packagist always adds type “drupal-module” for any contrib module. That’s an issue because directory path in Drupal core for database drivers should have been hardcoded. This is actually one of the points for improvements for future: drupal.org composer packagist needs to be compatible with database drivers. But this is a whole another story (a long story):
https://www.drupal.org/project/project_composer/issues/2924316
3. Mapping for data types. Drupal API supports all these data types: https://www.drupal.org/node/159605
All of those should have support for mapping, plus Drupal 8 had some new: like varchar_ascii. That was quite a challenge to have a proper support of all the similar new types!
4. Blob data. It creates lots of issues and inconveniences. For example, PDO length limits can vary, thus the correct limits for a definite instance should be determined. Currently, blob support was only ported from Drupal 7 version. To remind the current method of solving the problem: a separate table to store all blob data is created. Updates for a better solution may appear in future.
5. Drupal + Oracle installation. A lot of tricky things were done to make a fresh Drupal setup with Oracle database possible. From custom installation tasks to custom PDO statements objects to handle all Oracle-specific things: different syntax, other functions, escape reserved words, etc (80% of these solutions were ported from Drupal 7 project version, too).
Due to statistics, the project has a low conversion between downloads and installs. Well, this makes sense, as it had no support for almost four years (late 2013 - late 2017). The shortcoming of that period prevented lots of users from working further with the driver. Only in Nov 2017, it was updated to a 100% functional version.
There is still, and there will be, a lot of work to improve Drupal and Oracle integration. With the current project state though, we hope to strengthen Oracle Database position on the Drupal market!
P.S. This whole project is possible thanks to the development team of Drupal 7 module. Many regards to your contribution to D7 driver, which is a fundamental basis for this Case Study!
Why Drupal was chosen
To connect Drupal with Oracle database, one needs Drupal. The decision was tough but finally we decided to use Drupal :)
Technical Specifications
Drupal version:
Key modules/theme/distribution used:
It was a government project demand.