Might you be interested in moving this project to Drupal.org

[drupal-daffie]

Hi @mondrake, I see that you have worked in this project for a long time. I was wondering why you have this project on github and not on Drupal.org. If for some reason you want to keep it on github, that is perfectly fine too. I am working on getting contrib database drivers better support in Drupal core and on the DrupalCI testbot. If you might be interested in moving this project over to Drupal.org, what are you missing/holding you back for doing so? Can we work together to get those problems fixed. My idea was that when this project is on Drupal.org and has DrupalCI testbot support, the chance of getting Drupal core to switch to using this project in core would be a lot higher. Again, when you would rather stay on github, that is fine too. Just checking if we might work together to make Drupal core and DrupalCI testbot better for contrib database drivers.

[mondrake]

Hi @drupal-daffie, thank you for your interest!

TL, DR; No, I will not move this to drupal.org. It will not bring any benefit since the DBs it supports are already supported by the core drivers - and this will just add overhead.

I started this with a curiosity to see if we could easily switch Drupal DBTNG to Doctrine DBAL and so allow more DBs to be supported out-of-the-box, and to try running on Oracle. Neither of this materialized:
a) you can't just put DBAL on and off you go, you need to code (a lot of) workarounds that are DB specific (see the DBALExtension objects in the code). So, back to starting line in terms of abstraction.
b) Oracle support proved to be difficult for various reasons (Oracle not really supporting OSS environments for testing, DBAL schema manager rather inefficient for this DB, older Oracle versions allowing quite limited length of identifiers, etc.).

So this driver as such will not add much value, since as is it's just supporting DBs that are core supported already - adding additional code layers and overhead.

Doctrine DBAL has a few good things (the schema manager that makes changing database objects rather abstract, a way to manage sequences that is not bound to transactions,etc), but on the other side lacks some important things that Drupal DBTNG supports (upsert and merge constructs, union selects, distinct selects, etc), has a better dynamic query builder (support subselects, condition objects). Also, getting functional changes in Doctrine DBAL is a quite lenghty process.

I am keeping this experimental driver here up-to-date since it can help identify shortcomings in Drupal DB API when it comes to support contrib drivers (and it already has helped a lot!). Keeping it in github is better since access to TravisCI means much more flexible adjustment to test scripting than DrupalCI.

If in the future Drupal will look at alternatives to their DBTNG API, and Doctrine DBAL would be selected, then some of the code here could help. But that probably would require a wider rethinking of the DB layer - not just a DB driver in its current form.