mariadb/mysql-test/r/symlink.result

99 lines
3.1 KiB
Text
Raw Normal View History

drop table if exists t1,t2,t7,t8,t9;
drop database if exists mysqltest;
create table t1 (a int not null auto_increment, b char(16) not null, primary key (a));
create table t2 (a int not null auto_increment, b char(16) not null, primary key (a));
insert into t1 (b) values ("test"),("test1"),("test2"),("test3");
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
insert into t2 (b) select b from t1;
insert into t1 (b) select b from t2;
drop table t2;
insert into t9 select * from t1;
check table t9;
Table Op Msg_type Msg_text
test.t9 check status OK
optimize table t9;
Table Op Msg_type Msg_text
test.t9 optimize status OK
repair table t9;
Table Op Msg_type Msg_text
test.t9 repair status OK
alter table t9 add column c int not null;
show create table t9;
Table Create Table
t9 CREATE TABLE `t9` (
`a` int(11) NOT NULL auto_increment,
`b` char(16) NOT NULL default '',
`c` int(11) NOT NULL default '0',
PRIMARY KEY (`a`)
Bug#19025 4.1 mysqldump doesn't correctly dump "auto_increment = [int]" mysqldump / SHOW CREATE TABLE will show the NEXT available value for the PK, rather than the *first* one that was available (that named in the original CREATE TABLE ... AUTO_INCREMENT = ... statement). This should produce correct and robust behaviour for the obvious use cases -- when no data were inserted, then we'll produce a statement featuring the same value the original CREATE TABLE had; if we dump with values, INSERTing the values on the target machine should set the correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT = ... to do that). Lastly, just the CREATE statement (with no data) for a table that saw inserts would still result in a table that new values could safely be inserted to). There seems to be no robust way however to see whether the next_ID field is > 1 because it was set to something else with CREATE TABLE ... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column in the table (but no initial value was set with AUTO_INCREMENT = ...) and then one or more rows were INSERTed, counting up next_ID. This means that in both cases, we'll generate an AUTO_INCREMENT = ... clause in SHOW CREATE TABLE / mysqldump. As we also show info on, say, charsets even if the user did not explicitly give that info in their own CREATE TABLE, this shouldn't be an issue. As per above, the next_ID will be affected by any INSERTs that have taken place, though. This /should/ result in correct and robust behaviour, but it may look non-intuitive to some users if they CREATE TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have SHOW CREATE TABLE give them a different value (say, CREATE TABLE ... AUTO_INCREMENT = 1006), so the docs should possibly feature a caveat to that effect. It's not very intuitive the way it works now (with the fix), but it's *correct*. We're not storing the original value anyway, if we wanted that, we'd have to change on-disk representation? If we do dump/load cycles with empty DBs, nothing will change. This changeset includes an additional test case that proves that tables with rows will create the same next_ID for AUTO_INCREMENT = ... across dump/restore cycles. Confirmed by support as likely solution for client's problem.
2006-05-04 03:12:51 +02:00
) ENGINE=MyISAM AUTO_INCREMENT=16725 DEFAULT CHARSET=latin1 DATA DIRECTORY='TEST_DIR/var/tmp/' INDEX DIRECTORY='TEST_DIR/var/run/'
alter table t9 rename t8, add column d int not null;
alter table t8 rename t7;
rename table t7 to t9;
drop table t1;
2001-11-28 02:47:15 +01:00
Got one of the listed errors
Got one of the listed errors
Got one of the listed errors
Got one of the listed errors
Got one of the listed errors
alter table t9 rename mysqltest.t9;
select count(*) from mysqltest.t9;
count(*)
16724
show create table mysqltest.t9;
Table Create Table
t9 CREATE TABLE `t9` (
`a` int(11) NOT NULL auto_increment,
`b` char(16) NOT NULL default '',
`c` int(11) NOT NULL default '0',
`d` int(11) NOT NULL default '0',
PRIMARY KEY (`a`)
Bug#19025 4.1 mysqldump doesn't correctly dump "auto_increment = [int]" mysqldump / SHOW CREATE TABLE will show the NEXT available value for the PK, rather than the *first* one that was available (that named in the original CREATE TABLE ... AUTO_INCREMENT = ... statement). This should produce correct and robust behaviour for the obvious use cases -- when no data were inserted, then we'll produce a statement featuring the same value the original CREATE TABLE had; if we dump with values, INSERTing the values on the target machine should set the correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT = ... to do that). Lastly, just the CREATE statement (with no data) for a table that saw inserts would still result in a table that new values could safely be inserted to). There seems to be no robust way however to see whether the next_ID field is > 1 because it was set to something else with CREATE TABLE ... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column in the table (but no initial value was set with AUTO_INCREMENT = ...) and then one or more rows were INSERTed, counting up next_ID. This means that in both cases, we'll generate an AUTO_INCREMENT = ... clause in SHOW CREATE TABLE / mysqldump. As we also show info on, say, charsets even if the user did not explicitly give that info in their own CREATE TABLE, this shouldn't be an issue. As per above, the next_ID will be affected by any INSERTs that have taken place, though. This /should/ result in correct and robust behaviour, but it may look non-intuitive to some users if they CREATE TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have SHOW CREATE TABLE give them a different value (say, CREATE TABLE ... AUTO_INCREMENT = 1006), so the docs should possibly feature a caveat to that effect. It's not very intuitive the way it works now (with the fix), but it's *correct*. We're not storing the original value anyway, if we wanted that, we'd have to change on-disk representation? If we do dump/load cycles with empty DBs, nothing will change. This changeset includes an additional test case that proves that tables with rows will create the same next_ID for AUTO_INCREMENT = ... across dump/restore cycles. Confirmed by support as likely solution for client's problem.
2006-05-04 03:12:51 +02:00
) ENGINE=MyISAM AUTO_INCREMENT=16725 DEFAULT CHARSET=latin1 DATA DIRECTORY='TEST_DIR/var/tmp/' INDEX DIRECTORY='TEST_DIR/var/run/'
drop database mysqltest;
create table t1 (a int not null) engine=myisam;
show create table t1;
Table Create Table
t1 CREATE TABLE `t1` (
`a` int(11) NOT NULL default '0'
) ENGINE=MyISAM DEFAULT CHARSET=latin1
alter table t1 add b int;
show create table t1;
Table Create Table
t1 CREATE TABLE `t1` (
`a` int(11) NOT NULL default '0',
`b` int(11) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
show create table t1;
Table Create Table
t1 CREATE TABLE `t1` (
`a` int(11) NOT NULL default '0',
`b` int(11) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
drop table t1;
show create table t1;
Table Create Table
t1 CREATE TABLE `t1` (
`i` int(11) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
drop table t1;
show create table t1;
Table Create Table
t1 CREATE TABLE `t1` (
`i` int(11) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
drop table t1;