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.

CommentFileSizeAuthor
#1 minimum-mysql.patch1.41 KBcatch
minimum-mysql.patch579 bytescatch

Comments

catch’s picture

catch
he/him
Primary language English
commented
StatusFileSize
new minimum-mysql.patch1.41 KB

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.

liam mcdermott’s picture

liam mcdermott commented

Subscribing, and +1 from me.

Crell’s picture

Crell commented

A very unsurprising +1 from me as well.

Anonymous’s picture

Anonymous (not verified) commented

Subscribing with a plus one. I'm currently using version 5.0.41 on windows. Should we consider a patch level?

Crell’s picture

Crell commented

Yes we should, although I'm not sure what the best patch level to target would be. Someone get David Strauss in here. :-)

david strauss’s picture

david strauss
he/him
commented

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.

Anonymous’s picture

Anonymous (not verified) commented

Honestly, I value InnoDB support more than MySQL 5 support. Foreign keys (alone) would be a bigger leap forward than triggers and stored procedures.

Me too but that is a different issue.

Are there MySQL 5 features that we really want that we can't get from requiring InnoDB?

Increased performance for one even with InnoDB.

Crell’s picture

Crell commented

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. :-)

Anonymous’s picture

Anonymous (not verified) commented

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.

owahab’s picture

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.

Anonymous’s picture

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.

catch’s picture

catch
he/him
Primary language English
commented

At a minimum, Hostgator disables InnoDB on shared hosting (via google).

Either way, feel free to split requiring InnoDB over to a new issue ;)

dries’s picture

dries commented
Status: Needs review » Fixed

Committed to CVS HEAD. We can always rollback if it turns out to be problematic.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.