PHP 5.1 and MySQL 4.1

[Raven]

These have become pretty stable now. What are your plans for upgrading/migrating the servers. I have clients that I have had to turn away because I am not offering these versions. Thanks.

[Matt]

You have root on your server, you can install them if you like. There are several tutorials on how to run both php4 and 5 on the same server. But we won't support it now as it requires a lot of custom work.

You'll have to run php as a cgi when you run both versions I believe (if not both, certainly php5 is run as a cgi)

MySQL 5, not anytime soon either. [EDIT- MySQL 5.0 upgrades are being completed the week of August 13th, 2006)

We probably will not offer it on production servers until they are compatible with cPanel which is in beta now.

We will likely add a development server that has MySQL 5 and PHP5 and a possibility of Apache 2, and perhaps some other technologies.

That should satisfy some demand by the dev community until we see it as an option for the production servers.

We will make an announcement when we have a dev box online. If anyone would like to reserve a reseller account on this machine please PM me for a 20% discount. When we make plans available we will notify you and if you are interested you can use your 20% coupon.

[Raven]

Thanks for the reply. What about MySQL 4.1? That seems very stable now.

[Matt]

You can convert to 4.1 if you like, but the conversion is not backwards compatible so if you think you might want to go back to 4.0 (I don't see why there would be a need after a several successful upgrades) you should have your backups ready.

Most of your users will have authentication issues with their applications because the login style to mysql has changed.
To deal with that:

1. You can enable old style passwords or
2. Use the new style passwords and go into the config.php files and update them for the new format.

My vote is number 2, for numerous reasons.

[Matt]

All servers that are currently running MySQL 4.0 will be upgraded this month to 4.1 as a preliminary step towards support of PHP5+MySQL 5

cPanel and MySQL have had some compatibility issues lately, and as soon as these are resolved we plan to start the conversion to 4.1 for any remaining servers not currently on the mysql 4.1 tree.

This will bring us one step closer to PHP5 support that some of you have requested.

[Raven]

You can convert to 4.1 if you like, but the conversion is not backwards compatible so if you think you might want to go back to 4.0 (I don't see why there would be a need after a several successful upgrades) you should have your backups ready.

Most of your users will have authentication issues with their applications because the login style to mysql has changed.
To deal with that:

1. You can enable old style passwords or
2. Use the new style passwords and go into the config.php files and update them for the new format.

My vote is number 2, for numerous reasons.

Matt,

I'm already on 4.1.19 but still using the old style passwords. What else would be affected other than config.php?

[Matt]

Thats the main problem I have seen so far with upgrade from 4.0 to 4.1. Feel free to post if you see anything other than that but I have not had any problems outside of old passwords being a problem.

[jmarcv]

There are some issues with InnoDB commands in 4.1 that don't work in 4.0, but strictly upgrading and wanting to roll back, I don't really think there are any issues. There are some issues with timetamp formats in 5.0, but fairly sure they don't apply to 4.1

[jmarcv]

MySQL 4.0 to 4.1

• MySQL interprets length specifications in character column definitions in characters. (Earlier versions interpret them in bytes.) For example, CHAR(N) means N characters, not N bytes.
• In MySQL 4.1, string comparison works according to the SQL standard: Instead of stripping end spaces before comparison, the shorter string is extended using spaces. This means that 'a' > 'a\t', which it was not previously. If you have any tables containing an indexed CHAR, VARCHAR or TEXT column in which the last character in the index may be less than ASCII(32), you should use REPAIR TABLE or mysqlcheck to ensure that the table is correct.
• TIMESTAMP is returned in MySQL 4.1 as a string in 'YYYY-MM-DD HH:MM:SS' format. (See Section 11.3.1.2, “TIMESTAMP Properties as of MySQL 4.1”.) Display widths for TIMESTAMP columns are no longer supported in MySQL 4.1. For example, if you declare a column as TIMESTAMP(10), the (10) is ignored.
• Binary values such as 0xFFDF are assumed to be strings instead of numbers. This fixes some problems with character sets where it is convenient to input a string as a binary value.
• Before MySQL 4.1.1, the statement parser was less strict and its string-to-date conversion would ignore everything up to the first digit. As a result, invalid statements such as the following were accepted: "INSERT INTO t (datetime_col) VALUES ('stuff 2005-02-11 10:17:01')" As of MySQL 4.1.1, the parser is stricter and treats the string as an invalid date, so the preceding statement results in a warning.

[Matt]

Please see this thread.

MySQL 5 is being installed this week. One step closer to MySQL5+PHP5 on the production machines.