Add Percona Server to list of supported MySQL alternative databases.

-1

We should not continue this trend of adding every MySQL-compatible database to this list. I realize it's only one more in this patch, but if we're going to change it, let's change it to something like, "MySQL or MySQL compatible" (or revert to the old wording of "MySQL or equivalent"). This pretty much covers everything, and we don't have to keep tacking on new databases to the end of this list.

(Leaving at needs review, as my opinion is only one - I'm glad to hear what others will say)

Google Cloud SQL and Amazon RDS are two other services that are "MySQL compatible" (Amazon RDS can use MySQL under the hood). Anyways, my point is, we ship with a .htaccess file because we assume that Drupal is going to be used with Apache. This doesn't actively prevent anyone from running Drupal under nginx or the like, but we do expect that if somebody is going to use an alternate service, they are going to know what they're doing.

To me, this is the same. We could just as easily say "MySQL" (with no qualifying text) and just expect that if somebody is going to use something else, they'll know what they're doing enough to recognize that it just has to be mysql compatible.

I agree it's not really a strong reason for voting down the patch, but on principle, I disagree with this direction.

That said, the code looks fine and if this is the direction we decide we want to go, I'm fine with it. Just voicing my disagreement :)

It's worth pointing out that MariaDB was added to that string in #861192: Document that MariaDB works, too. This was specifically done because Oracle bought MySQL and the community felt it was very important to highlight the open source community alternative right there in peoples' faces.

I do not know where Percona fits into the MySQL ecosystem, but we would need to come up with a similar "special" reasoning for adding Percona here, or else it will indeed sprawl into a never-ending list of compatible DBs.

Also, Dries was keen to see this happen, so assigning to him.

One other thing to note here: if we add Percona to this list, and there's some customization in Percona that works slightly different than MySQL, who's responsible for fixing it? I can see situations like this where there's a bug/"feature" in Percona causing an issue with a site, but Drupal is incorrectly blamed for it (note that this is just speculation - I avoid Percona and prefer MariaDB when possible, so I don't have a strong background on what customizations are in Percona).

So I guess my question is, is there a difference between which databases will probably work and which databases we officially support?

Cool, that's helpful. I will also say that whenever I've heard of Percona, it's been in relation to high-performance installations, so that may be the big differentiator that warrants its inclusion in the list.

it becomes Percona's problem

If that's the case, then I'm good with this :)

Yep, as mentioned before, any differing behaviour that would cause Drupal to break we'd consider a bug (either that, or it's a bug in how Drupal uses the database and would mean that it could likely break on any subsequent MySQL version too - but i'd still argue that it'd be a PS bug)

I think it makes sense to list Percona. Percona is a great alternative that has proven to work well. For many, using Percona is a best practice actually. It is something that we want to encourage.

   - MySQL 5.0.15 (or greater) (http://www.mysql.com/).
   - MariaDB 5.1.44 (or greater) (http://mariadb.org/). MariaDB is a fully
     compatible drop-in replacement for MySQL.
+  - Percona Server 5.1.70 (or greater) (http://www.percona.com). Percona
+    Server is a backwards-compatible replacement for MySQL.

Is it me, or those version numbers start looking more and more random?

Dries answered in #14, so I think this is fair game for any core maintainer to commit.

Oops. Thought this went in a long time ago.

Committed and pushed to 8.x. Thanks!

I guess we should maybe backport to D7 as well?

Straight backport, patch attached.

I am not sure we want to change the translated text in the UI for Drupal 7. That has implications for translating Drupal.

Yeah, anything wrapped in st()/t() gets translated. The impact would be that all translators would have to update their translations, else people would see that english string in amongst their french/hungarian/etc.

Doc comments do not get translated. Like most international software projects, we write all code comments in English and hope/expect that all our core developers can read them enough to get the gist.

Text inside t() gets translated, and in D7, also in functions st() or get_t() -- that is text meant for end users of the software (just the first parameter to these functions gets translated, however -- the rest is substitutions like URLs). So the text "MySQL, MariaDB, or equivalent" is translated, and it's already in the language database files that you can download for many languages. If we change it to read "MySQL, MariaDB, Percona Server, or equivalent", then when someone tries to make, for instance, a Chinese site, the new text wouldn't match what is already in the language database when Drupal tried to look up the translation, so they'd see this English text in the middle of their screen. Oops!

So our policy after a release has been made is that unless there is a blatantly incorrect piece of translated text, we try not to modify it for minor issues like typos or slight improvements. And I think adding Percona would not qualify as something important enough to need to consider modifying translated text.

We can make the INSTALL.txt change. Accordingly.. the patch needs work.

The latest patch looks fine.

Regards,
K.

Thanks! Committed to 7.x.