Re: [drupal-devel] MySQL 3, MySQL 4 and MySQL 5
Speaking for myself, I am already on 4.0.18 on my test machine at home, and 4.0.24 on my hosting account. So, for me, 3.x support can go away. Perhaps a poll on Drupal.org on "what version of MySQL is your hosting company using" give us an idea on how much of each is out there in the field. --- Date: Sun, 1 May 2005 19:25:34 +0200 From: Dries Buytaert <dries@buytaert.net> Subject: [drupal-devel] MySQL 3, MySQL 4 and MySQL 5 To: drupal-devel@drupal.org Message-ID: <81a18f63b2f53464852d8e6d94ccf48f@buytaert.net> Content-Type: text/plain; charset=US-ASCII; format=flowed At what point should we drop MySQL 3 support? MySQL 4 has been released on October 21, 2001 [1] and a MySQL 5 BETA release is already available from [2].
From my investigation, making MySQL 4 a requirement would allow us to use row-level locking and transactions, two features that are becoming increasingly important. If would allow us to get rid of the various MySQL errors, and would bring us one step closer to true database integrity. It would be nice if we could take advantage of these in Drupal 4.7.
[1] http://www.mysql.com/news-and-events/news/article_81.html [2] http://dev.mysql.com/downloads/mysql/5.0.html Thoughts?
Making something reliant on InnoDB is a big mistake. Though they are better in many aspects, they are not available everywhere. The caveat here is that MySQL will let you say "CREATE TABLE ... Type=InnoDB" even if you DO NOT have InnoDB functionality in the back end. I tested this myself on a server running Mandrake Linux, and the behavior is what I outlined above: no error given, nothing. The user could be fooled into thinking they are running InnoDB while they are not. I would imagine that MySQL will allow you to have FOR UPDATE on MyISAM tables, and will simply ignore it, like it does in many other statements it does not support. On servers that you have control of, you must load a package called MySQL-MaxDB to get Inno support. Since most people are on shared hosting, this would be a source of great confusion, and perhaps serious problems (assume that locking is happening while it is not, ...etc.) So, we have to be careful with mandating InnoDB. If we do, it has to be an option, not mandatory. --- Gerhard says: On Mon, 2 May 2005, Karoly Negyesi wrote:
Do you have experience with using InnoDB? Does it have other (dis)advantages? Should we consider to use InnoDB for some tables?
No. Slow.
I think this is too narrow minded. If InnoDB would give us some usefull features, we should consider to try using them and do benchmarks. I can imagine that for some tables being a bit slow isn't a real problem, but row based locking might be a significant improvement. For example we could have a "locks" table that looks similar to this:
The caveat here is that MySQL will let you say "CREATE TABLE ... Type=InnoDB" even if you DO NOT have InnoDB functionality in the back end.
I tested this myself on a server running Mandrake Linux, and the behavior is what I outlined above: no error given, nothing. The user could be fooled into thinking they are running InnoDB while they are not.
I would imagine that MySQL will allow you to have FOR UPDATE on MyISAM tables, and will simply ignore it, like it does in many other statements it does not support.
Well, I test it on my local install of MySQL (3.23.58) and my shared hosting (free.fr 4.0.22). You can create InnoDB tables, but you won't get any errors and as you say you won't even notice you are not using InnoDB tables until you made an export, or using phpMyAdmin in the operation tab to check table's format. We get the same behaviour for SELECT ... FOR UPDATE. No error message is displayed but no lock is made :(
participants (2)
-
K B -
Nicolas Tostin