Drupal and the spirit of openness

This blog post is more than 6 years old, so the content may be out of date.

So what does it take to get accepted around here?
I've started this post to kick off a discussion about the Drupal database abstraction layer, and how to encourage support for other databases.

The problem

Collaborating on Drupal modules or Drupal themes is easy. If you have a module/theme you would like to contribute, you need a CVS account on drupal.org. There's an application form, a clear, well-documented CVS application process, and detailed guidance on what the application-reviewers are looking for.

However, DB abstraction does not fit into module-space. You can't add a new DB provider via a module, and whilst a module may provide useful DB features (e.g. statistics, connection information, etc) DB abstraction code shouldn't depend on a particular module either.

At the moment, Drupal doesn't a mechanism for accepting third-party database driver code, so in some cases it's been added as though it were a module:

There may well be others; these are the ones I happen to know about.

How to get accepted?

The issue is a simple question: What are the requirements to get a new DB abstraction layer accepted?
The MS SQL patch is a great example: it's had input from Drupal luminaries such as moshe, Damz, and even Dries has added his support. But the patches languish in code purgatory because there is no process for accepting DB drivers.

The challenges

The mega-thread explains a few of the challenges for managing third-party db drivers.

  • Usage-tracking
    Statistics on module/theme/nnn usage helps the drupal community assess a particular code-release, and make informed decisions on the benefits of adopting the code. Usage tracking is available for modules and themes, but db-abstraction doesn't belong there, so there's no reasonable way to track this.
    I wouldn't describe this as a critical issue or blocker, but it's definitely a significant benefit and should be part of any long-term plan
  • Updating / security-alerts
    The drupal security team do an *awesome* job of reviewing and notifying security issues, and working with module developers to resolve them. All this is built into drupal.org's project system (and Drupal's core update module.). There isn't such a process or mechanism for db-abstraction code, which means that a security issue in a DB layer may be recognised but not have a mechanism to issue an automated security-alert.
  • Testing
    I'm sure that we all realise by now that automated tests are a Good Thing. Patches committed to the issue-queue are pushed through Drupal's automated test-suite and the results are reported in the issue-queue. Any DB-driver should be subject to the same set of tests so that issues can be addressed before being released.


In short, I think we should:

  • Publish a statement on d.o. to explain how a third-party db-driver can be contributed, and what the criteria for acceptance will be (much like we do for CVS applications)
  • Update drupal.org to support submission of database drivers. This will probably mean:
    • a new 'database driver' category (to supplement module, theme, etc)
    • patching the project and update modules to support usage-tracking and security-advisory reporting on db-drivers
    • adding db-abstraction testing to the test infrastructure
  • Migrate the existing contributions to the new framework (or support the original contributors with the migration)

Why are we doing this again?

Drupal is a tale of continual success: the core gets better and better, the take-up statistics graph is thoroughly impressive, and drupalcon picks up a large audience every year. So naturally, large organisations want to get involved: companies like Oracle and Microsoft would love to get a look-in. And my question is: why on earth should we refuse them? Fundamentally, we should be looking at every submission and asking ourselves: does this make Drupal better?

Drupal's code submission rules are clear: code submitted to d.o. is GPLd. The code can be used by Drupal, from now until forever, for free. We should welcome any contribution that allows Drupal to spread further and encourages more organisations to get involved. And that shouldn't be without caveats: we have limits on CVS contributions, and they should apply to DB code submissions too. It would be irresponsible to do otherwise.

Which is why we should - as a community - agree what the standard should be for accepting DB code, and publish those, so third parties such as Microsoft, Oracle, et al know what we expect as a community.

For the record, if modules - such as project and update - need patching to support these features, I'm there...They'll be top of my todo queue.

Full disclosure: Microsoft have invited me to their conferences in the past, and I'm proud to have developed a few modules with their team - such as the zoomit module. I've found them to be fully supportive of open-source and Drupal. Microsoft recently released a native PHP driver for MS SQL, and they would love to support Drupal in taking advantage of it. I've found them incredibly supportive, and their expertise - offered for free - a huge asset. I think we'd be doing the Drupal community a massive disservice to turn them away.


MongoDB and Cassandra are not SQL databases. They have no relation to Drupal's database layer, which is SQL specific. They tie into Drupal at much higher places in the stack, like Field storage engines or Cache backends. They are not germain to this conversation.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <apache>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo]. PHP source code can also be enclosed in <?php ... ?> or <% ... %>.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.