Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | minimum-mysql.patch | 1.41 KB | catch |
| minimum-mysql.patch | 579 bytes | catch |
Comments
Comment #1
catchmissed 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.
Comment #2
liam mcdermott commentedSubscribing, and +1 from me.
Comment #3
Crell commentedA very unsurprising +1 from me as well.
Comment #4
Anonymous (not verified) commentedSubscribing with a plus one. I'm currently using version 5.0.41 on windows. Should we consider a patch level?
Comment #5
Crell commentedYes we should, although I'm not sure what the best patch level to target would be. Someone get David Strauss in here. :-)
Comment #6
david straussHonestly, 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.
Comment #7
Anonymous (not verified) commentedMe too but that is a different issue.
Increased performance for one even with InnoDB.
Comment #8
Crell commentedMany 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. :-)
Comment #9
Anonymous (not verified) commentedHmm... 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.
Comment #10
owahab commented+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.
Comment #11
Anonymous (not verified) commented@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.
Comment #12
catchAt a minimum, Hostgator disables InnoDB on shared hosting (via google).
Either way, feel free to split requiring InnoDB over to a new issue ;)
Comment #13
dries commentedCommitted to CVS HEAD. We can always rollback if it turns out to be problematic.
Comment #14
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.