Up minimum MySQL version to 5.0
catch - February 11, 2008 - 12:45
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | database system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
http://lists.drupal.org/archives/development/2008-02/msg00125.html
There's bound to be more references to 4.1 in core (I think 4.0 is pretty much expunged as of 6.x though at least), and probably we'd want to pick a minor release rather than "5.0" but let's get started.
| Attachment | Size |
|---|---|
| minimum-mysql.patch | 579 bytes |
#1
missed INSTALL.txt otherwise version information doesn't seem to be mentioned explicitly anywhere in core except for a note about mysqli where it makes sense anyway.
#2
Subscribing, and +1 from me.
#3
A very unsurprising +1 from me as well.
#4
Subscribing with a plus one. I'm currently using version 5.0.41 on windows. Should we consider a patch level?
#5
Yes we should, although I'm not sure what the best patch level to target would be. Someone get David Strauss in here. :-)
#6
Honestly, I value InnoDB support more than MySQL 5 support. Foreign keys (alone) would be a bigger leap forward than triggers and stored procedures. Are there MySQL 5 features that we really want that we can't get from requiring InnoDB?
As for patch levels: FourKitchens.com (and the other sites on the server) are running MySQL 5.0.45 on RHEL 4, and we haven't had problems. RHEL 4 only includes MySQL 4.1, so that gives no common patch level to target there. Stratfor.com runs CentOS 5 with the included MySQL 5.0.22 (and course Red Hat's extra patches), and we haven't had trouble with that under InnoDB with heavy load and foreign keys, either.
In any case, I think the best approach is to begin Drupal 7 development without a predefined MySQL patch level. If we hit show-stopping bugs, we can increase the requirements as necessary to get the patches we need while considering what major platforms and hosting companies we leave behind. If we'd have to drop too much support, we can then look at workarounds. Checking the MySQL patch level has become part of my standard bug hunting procedure.
#7
Me too but that is a different issue.
Increased performance for one even with InnoDB.
#8
Many shared hosts only offer MyISAM. Most shared hosts that I know of are moving to MySQL 5.0.x, if grudgingly. I don't think we can get away with requiring InnoDB, at least not without a GoInnoDB5.org movement. :-)
#9
Hmm... I thought InnoDB was included by default in version 5.x. Oh, well, I will still require it for my publisher module since it requires the use of transactions.
#10
+1 for dropping MySQL 4.x.
InnoDB support is, IMHO, totally off topic. Despite Oracle announcement that they will be negotiating renewal of contract between MySQL and Innobase, I personally do not think this will happen.
Instead, by the time D7 will be released, Maria will be already in MySQL 5.
#11
@Crell: For the record, I just checked my configure of the source of MySql and I did nothing special to include the InnoDB engine. This means I was correct in that InnoDB is included by default.
#12
At a minimum, Hostgator disables InnoDB on shared hosting (via google).
Either way, feel free to split requiring InnoDB over to a new issue ;)
#13
Committed to CVS HEAD. We can always rollback if it turns out to be problematic.
#14
Automatically closed -- issue fixed for two weeks with no activity.