Description:
have not tested with earlier versions.
Modify federated.test like this:
===== t/federated.test 1.24 vs edited =====
*** /home/mysql_src/mysql-5.1-new/BitKeeper/tmp/bk_federated.test-1.24_CPRbXV 2006-03-07 20:00:41 +01:00
--- edited/t/federated.test 2006-05-13 13:58:31 +02:00
***************
*** 153,158 ****
--- 153,159 ----
ENGINE="FEDERATED" DEFAULT CHARSET=latin1
CONNECTION='mysql://root@127.0.0.1:$SLAVE_MYPORT/federated/t1';
+ set auto_increment_increment=20;
INSERT INTO federated.t1 (name, other) VALUES ('First Name', 11111);
INSERT INTO federated.t1 (name, other) VALUES ('Second Name', 22222);
INSERT INTO federated.t1 (name, other) VALUES ('Third Name', 33333);
and observe that the output of the SELECT which comes next:
...
INSERT INTO federated.t1 (name, other) VALUES ('Ninth Name', 99999);
INSERT INTO federated.t1 (name, other) VALUES ('Tenth Name', 101010);
# basic select
SELECT * FROM federated.t1;
does not change, that is the INSERTs have still used values 1,2,3 etc
for the auto_increment column instead of the expectable 1,21,41,etc.
I can understand why it's like this (honouring
auto_increment_increment and auto_increment_offset would require
passing their values to the remote mysqld), but I couldn't find it in
the "federated engine limitations" section of our manual.
There may be other variables with the same problem, haven't searched.
Is it a bug to fix or a limitation to document?
Filing a bug report here at PatrickG's request.
How to repeat:
see description