WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#16091 closed feature request (maybelater)

Revise WPDB implementation to use DB agnostic syntax (where possible) and support pluggable DB-specific functions

Reported by: sc0ttkclark Owned by:
Milestone: Priority: normal
Severity: major Version: 3.1
Component: Database Keywords:
Focuses: Cc:

Description

I believe the current DB class, as well as many queries within core of WP outside the DB class, are limiting the growth of WordPress in non-MySQL environments.

I realize that there are existing efforts on behalf of big companies who are using roundabouts to "MacGyver" their way around the problem, but this needs to be solved at the root source which is the DB class used in WP, and the queries used throughout core which contain MySQL-specific SQL.

As an example of a DB abstraction layer we could look into using, check out DBTNG:

https://github.com/Crell/DBTNG

You may be familiar with it already if you've ever poked around Drupal. Except this code has been forked from Drupal in the hopes that Drupal and other systems can share it to further each other's abilities. The maintainer of the new project is also someone who works on DBTNG within Drupal core.

I'm hoping this can be looked into and discussed in depth fully before 4.0 rolls around. I realize this is years ahead of time, but such a change I believe requires a great deal of thought, planning, and preparation.

I understand there's no 4.0 milestone yet, so please mark it as Future Release and keep it on your radars.

Change History (19)

comment:1 @sc0ttkclark5 years ago

BTW, I haven't listed all of the pros / cons of such a change but I'm leaving that to be discussed further by people who aren't sick today :)

comment:2 @brianlayman5 years ago

You're gonna lose a lot of people at the mention of Drupal ;) It feels like making Coke out of Pepsi syrup to make it sweeter.

Joking aside, you'll need to educate people about this. For example:how is switching to DBTNG better than merging the current EZSQL updates back into wpdb or even switching to ADOdb?

comment:3 @sc0ttkclark5 years ago

It is my understanding that EZSQL is no longer maintained, or so Vincent had told me himself. As for ADOdb, I'll work on posting a comparison between DBTNG and ADOdb for you, but the primary differences are noted in comparisons made between ADOdb and PDO since DBTNG utilizes PDO.

Let me make it very clear that I'm for WP evolving, I'm not glued to DBTNG but I thought that having a standardized layer used across multiple systems (there are other GPL systems looking into using DBTNG as well) may benefit the greater good.

comment:4 @scribu5 years ago

  • Cc scribu added

comment:5 @sc0ttkclark5 years ago

From Larry Garfield, the maintainer:

I can't compare DBTNG and ADOdb directly, as I have not really used ADOdb.
DBTNG originally was intended as a very thin set of tools to wrap SQL, not a
complete and all-encompassing database library; it evolved into a fairly solid
and robust database library over time through lots of good patches and careful
curation of the design and architecture with an eye toward making it
minimally-dependent on Drupal. That it ended up as an almost-viable stand-
alone library is a very nice side-effect and one that we are excited to try
and exploit, but was not one of the original explicit design goals.

We were approached by developers from Doctrine very early on to see if we
wanted to just adopt Doctrine. We considered that briefly but decided against
it for a couple of reasons.

1) Drupal has a poor history with leveraging 3rd party libraries, as its
archtiecture tends toward integrated solutions rather than stitching together
separate systems.

2) Doctrine at the time was, I believe, larger than Drupal core itself, and we
were looking for a lightweight solution, not to double the size of Drupal.

3) Doctrine attempts to be an ORM using its own SQL-esque string syntax, which
we believed was not a good architectural direction. DBTNG is not an ORM nor
does it attempt to be.

Some more background on DBTNG's architectural decisions can be found here:

http://www.garfieldtech.com/blog/orm-vs-query-builders

Version 0, edited 5 years ago by sc0ttkclark (next)

comment:6 @sc0ttkclark5 years ago

From David Timothy Strauss, a contributor / co-maintainer:

I'm personally proud of the transaction support we've built.

CiviCRM already uses an early incarnation of this work -- which became the basis for Drupal's -- but we (the Drupal community) have extended it into something really impressive. I think it's the most elegant transaction model available. In comparison, ADODB's "smart" transactions allow nesting, but they don't have the awesome savepoint nesting and scope-based COMMITs that Drupal's library has.

That's at least one reason to consider this library.

comment:7 @scribu5 years ago

I've read the article on garfieldtech.com - very interesting read, but it seems to reach the same conclusion WP has: the only feasible approach at the moment is to write portable SQL queries.

As for transactions, they're not used in Core, so there's no immediate benefit on that front.

comment:8 @nacin5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

We've long ago forked EZSQL. It's not an external library at this point.

We have no plans to do this. Closing.

comment:9 @sc0ttkclark5 years ago

You're saying that the Core team has no plans to do this - currently - however I'm slating this for a 4.0 discussion, which is further ahead and assuming WP grows to a point in which MySQL-only support becomes an unnecessary barrier. Simply building custom WPDB classes and plugging them in, or creating short term solutions that don't solve the larger root issues seems to me to be something that should be up for discussion within core.

Is there a specific reason this ticket must remain closed beyond being something not currently planned? Or can the subject of this ticket even be discussed in depth by Core developers and contributors without the burden of the dead ended 'closed' / 'wontfix' ticket? I don't want to get into a close/reopen war on this ticket. :)

This ticket represents a cultural shift within WP Core to become more database agnostic in it's query syntax and DB abstraction - whether that be replacing or methods of overhauling the current WPDB implementation.

4.0 is quite a while a way and I believe discussion and attention is merited to increase the interoperability and expanded use of WP.

Last edited 5 years ago by sc0ttkclark (previous) (diff)

comment:10 @sc0ttkclark5 years ago

  • Summary changed from Replace current DB class with a robust standardized DB abstraction layer to Revise WPDB implementation to use DB agnostic syntax (where possible) and support pluggable DB-specific functions

comment:11 @nacin5 years ago

4.0 is an arbitrary distinction. It's no different that 3.9 or 4.1. If we ever decide to this in the future, it won't be because this ticket is sitting around. I'm quite literally sitting around a dinner table at the moment with the other core developers, after a day of discussing the future of WordPress, and we have no desire to have rotting tickets reminding us of "cultural shifts" that isn't on our roadmap in any sense. (Hence a new resolution, maybelater, which should provide a glimmer of hope without any kind of promise.)

comment:12 @sc0ttkclark5 years ago

Of course if you decide to do this it won't be because of this ticket. I'm not claiming ownership of this idea. I'm merely saying use this as a vehicle to promote further discussion, patch ideas, and in your case as a place to list reasons why it's not something that can be included in a future release.

From what I've seen, the best way to get something going is to work on and provide patches, discuss amongst contributors / devs best ways to accomplish things, and someone spends time on it to push the idea forward. It's happened before, so why couldn't it happen now?

Do you believe this ticket is too big and needs to be split into smaller more digestible tickets? I could understand that, but rejection of the entire idea (as explained throughout the ticket and more clearly in my last response) leaves me confused as I only picked up the context of "we don't want to." Could you provide some insight as to why it won't be pursued (and if it's a matter of man power, or if you just need some one to "own" it and push the idea into patches, testing, etc) in the near future?

comment:13 @sc0ttkclark5 years ago

Also, given your description of the release cycle, then there's nothing saying it can't be done earlier than 4.0 like 3.2 or 3.3 for instance, so it wouldn't "rot" for long, especially if a few other people hop in and offer their thoughts and critique of proposed patches.

comment:14 @sc0ttkclark5 years ago

  • Keywords 4.0 removed

comment:15 @scribu5 years ago

I think it's one of those things which won't change unless absolutely necessary, i.e. when we think about adding offline support (which presumably would require SQLLite). So, there's little practical reason to discuss it until then.

comment:16 @sc0ttkclark5 years ago

I'm going to post a few easily digestible tickets with patches, we'll see where they go but I'll start simple first and then eventually maybe we'll be able to do something with that mysql_query down the road :)

comment:17 @mikeschinkel5 years ago

  • Cc mikeschinkel@… added

comment:18 @sc0ttkclark4 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:19 @sc0ttkclark4 years ago

  • Resolution set to maybelater
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.