Why we moved the database drivers to their own modules

daffie — Sat, 22 Apr 2023 09:51:10 +0000

Room

HS13 (2nd floor)

daffie Sat, 04/22/2023 - 11:51

Time Slot

Fri 11:45am to 12:15pm (7/21/23)

Session length

Short session - 25min, including Q&A

Audience

Intermediate

Session Category

Innovation & The future

In Drupal 9.4 the database drivers for MySQL, MariaDB, PostgreSQL and SQLite were moved to their own modules. This session is about why we did that and what we want to do next.

We had a number of problems with the old situation:

1. Having contributed modules with a database driver copy their driver files to the directory drupal_root/drivers is not very composer friendly.

2. The database driver classes are unfortunately not enough to make Drupal work for a specific database. All database drivers need to override things like (views and other) plugins and entity storage classes. Those overrides need to live in a module

3. Tests are not always the same for every database driver. Those overrides also need to live in a module.

4. The by Drupal core supported database drivers are the example for contributed database drivers. Just like the Drupal core module and themes are the example for the contributed module and themes.

5. Database drivers should be able to extend another database driver. Just like modules can do.

Having the by Drupal core supported database drivers in their own modules makes it possible to do:

A. Create a new database driver for MySQL that allows queries to be run asynchronously. For instance with multiple blocks on a page, the block data can be loaded in parallel from the database instead of synchronously. PHP 8.1 has added the Fibers functionality and that allows I/O and database queries to run asynchronously. The database driver for MySQLi allows Drupal to use asynchronous queries.

B. Store content entity data in a document format. Content entity data is now stored in multiple tables and with a high number of entities, getting entity data out of the database will become slow. When used in combination with authenticated users and a lot of content, will result in Drupal becoming slow. Storing content entity data in a document format will make it fast again. The only database that a the moment has enough functionality to make it work with Drupal is MongoDB.
Using caching is great, but has it limitations. If we make hard Drupal calls a lot faster, we can use Drupal without any caching or with a lot less. PHP is fast enough for this. Databases are fast too. Only storing data following the relational database rules makes will result in complicated queries for getting the data out of the database. Complicated queries with large amounts of data will result in a performance nightmare. That is why we are using so much caching with Drupal sites. For anonymous users this is not a problem, only with authenticated users is caching a lot of times not possible. The solution is to store content entity data in a document format. In that way we almost always can get the data out of the database with a simple query (and therefor a fast query). When all queries are simple queries, the resulting Drupal page call will be fast.

I have already build a database driver for MongoDB. The driver is in the form of a Drupal module and the project can be found here: https://gitlab.com/daffie/mongodb867. It is based on Drupal 8.6.7 it hacks Drupal core with a >1.5 MB patch file. This is totally not maintainable. To fix that problem I have started to work on Drupal core to make the MongoDB database driver module work without patching/hacking Drupal core.

I would like to end with a group discussion about what we want to do next. What does the group think. Do they have other/new ideas. Hopefully get other people involved in what is next. This can also happen after the official session.

Speaker(s)

David Bekker

Drupal developer at Finalist

Speaker biography

David Bekker

I am the main contributor in having the database drivers moved to their own modules, I am also the subsystem maintainer for the Database API and I have over 500 Drupal core commit credits.

Session Keywords

How to write maintainable large scale software

kristiaanvandeneynde — Fri, 24 Mar 2023 09:38:28 +0000

How to write maintainable large scale software

Room

HS1 (Ground level)

kristiaanvandeneynde Fri, 03/24/2023 - 10:38

Time Slot

Wed 2:00pm to 2:45pm (7/19/23)

Session length

Long session - 45min, including Q&A

Audience

Intermediate

Session Category

Backend Development

Over the years of writing the Group module I have come to many occasions where I regretted writing some code that was now making my life miserable. I've tried to learn from these mistakes and managed to take away a few important lessons.

In this session, it would be my pleasure to teach some of these lessons I've had to learn the hard way. Topics that I'll cover include writing single responsibility code, abstracting out systems that can serve different purposes and taking plenty of time to properly architect your code.

We'll also go into some of my most painful mistakes to date and how I fixed them.

Speaker(s)

Kristiaan Van den Eynde

Senior Drupal developer at Factorial GmbH

Speaker biography

Kristiaan Van den Eynde

Author and maintainer of the Group module. Have been working with Drupal for well over a decade and have presented at various Drupal Cons, Camps and Dev Days.

Session Keywords