[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Several visible behaviors have changed between MySQL 4.0 and MySQL 4.1 to fix some critical bugs and make MySQL more compatible with the ANSI SQL standard. These changes may affect your applications.
Some of the 4.1 behaviors can be tested in 4.0 before performing
a full upgrade to 4.1. We have added to later MySQL 4.0 releases
(from 4.0.12 on) a --new
startup option for mysqld
.
This option gives you the 4.1 behavior for the most critical changes.
You can also enable these behaviors for a given client connection with
the SET @@new=1
command, or turn them off if they are on with
SET @@new=0
.
If you believe that some of the 4.1 changes will affect you,
we recommend that before upgrading to 4.1, you download
the latest MySQL 4.0 version and run it with the --new
option by
adding the following to your config file:
[mysqld-4.0] new |
That way you can test the new behaviors in 4.0 to make sure that your
applications work with them. This will help you have a smooth painless
transition when you perform a full upgrade to 4.1 later. Doing it the
above way will ensure that you don't accidently later run the 4.1
version with the --new
option.
The following list describes changes that may affect applications and that you should watch out for when upgrading to version 4.1:
TIMESTAMP
is now returned as a string in 'YYYY-MM-DD HH:MM:SS'
format. (The --new
option can be used from 4.0.12 on to
make a 4.0 server behave as 4.1 in this respect.) If you want to have
the value returned as a number (like Version 4.0 does) you should add +0 to
TIMESTAMP
columns when you retrieve them:
mysql> SELECT ts_col + 0 FROM tbl_name; |
Display widths for TIMESTAMP
columns are no longer supported.
For example, if you declare a column as TIMESTAMP(10)
, the (10)
is ignored.
These changes were necessary for SQL standards compliance. In a future version, a further change will be made (backward compatible with this change), allowing the timestamp length to indicate the desired number of digits for fractions of a second.
0xFFDF
now are assumed to be strings instead of
numbers. This fixes some problems with character sets where it's
convenient to input a string as a binary value. With this change,
you should use CAST()
if you want to compare binary values
numerically as integers:
mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER); -> 0 |
If you don't use CAST()
, a lexical string comparison will be done:
mysql> SELECT 0xFEFF < 0xFF; -> 1 |
Using binary items in a numeric context or comparing them using the
=
operator should work as before. (The --new
option can
be used from 4.0.13 on to make a 4.0 server behave as 4.1 in this respect.)
DATE
, DATETIME
, or TIME
value, the result returned to the client now is fixed up to have a temporal
type. For example, in MySQL 4.1, you get this result:
mysql> SELECT CAST("2001-1-1" as DATETIME); -> '2001-01-01 00:00:00' |
In MySQL 4.0, the result is different:
mysql> SELECT CAST("2001-1-1" as DATETIME); -> '2001-01-01' |
DEFAULT
values no longer can be specified for AUTO_INCREMENT
columns. (In 4.0, a DEFAULT
value is silently ignored; in 4.1,
an error occurs).
LIMIT
no longer accept negative arguments.
Use 18446744073709551615 instead of -1.
SERIALIZE
is no longer a valid mode value for the sql_mode
variable. You should use SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
instead. SERIALIZE
is no longer valid for the --sql-mode
option
for mysqld
, either. Use --transaction-isolation=SERIALIZABLE
instead.
SHOW CREATE TABLE
and mysqldump
.
(MySQL versions 4.0.6 and above can read the new dump files; older
versions cannot.)
mysqldump
.
See section mysqldump
.
--shared_memory_base_name
option on all machines.
xxx_clear()
function for each aggregate function XXX()
.
In general, upgrading to 4.1 from an earlier MySQL version involves the following steps:
Important note: Early alpha Windows distributions for MySQL 4.1 do not contain any installer program. See 2.2.1.2 Installing a Windows Binary Distribution for instructions on how to install such a distribution.
Password
column that is needed for secure handling of passwords. The
procedure uses mysql_fix_privilege_tables
and is described
in 2.5.8 Upgrading the Grant Tables.
The password hashing mechanism has changed in 4.1 to provide better security, but this may cause compatibility problems if you still have clients that use the client library from 4.0 or earlier. (It is very likely that you will have 4.0 clients in situations where clients connect from remote hosts that have not yet upgraded to 4.1). The following list indicates some possible upgrade strategies. They represent various tradeoffs between the goal of compatibility with old clients and the goal of security.
mysql_fix_privilege_tables
script
to widen the Password
column in the user
table so
that it can hold long password hashes. But run the server with the
--old-passwords
option to provide backward compatibility that
allows pre-4.1 clients to continue to connect to their short-hash
accounts.
Eventually, when all your clients are upgraded to 4.1, you can stop using the
--old-passwords
server option. You can also change the passwords for
your MySQL accounts to use the new more secure format.
mysql_fix_privilege_tables
script to widen the
Password
column in the user
table. If you know that all clients
also have been upgraded to 4.1, don't run the server with the
--old-passwords
option. Instead, change the passwords on all existing
accounts so that they have the new format. A pure-4.1 installation
is the most secure.
Further background on password hashing with respect to client authentication and password-changing operations may be found in 5.4.7 Password Hashing in MySQL 4.1.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |