1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Matthias 17.06.2005
-------------------
1. I changed the database test1 (dropped + created in SP test)
to test4.
Please adjust the SP test cases.
2. There is a difference between my definition of
innodb_tb4 + memory_tb4
to the latest table definition used by disha.
Please adjust the table definition if needed.
3. The data load files are product of the Disha data generation script
(downloaded ~20 May ?) + modified by Omer
These load data fit fairly to the table definitions.
4. How to execute the "small" test with 10 rows per table.
Do NOT set the environment variable NO_REFRESH to a
value <> ''.
Start the test for example by
./mysql-test-run.pl --vardir=/dev/shm/var \
--force --suite=funcs_1 --do-test=myisam
The "result" files fit mostly to this variant.
Any database not in ('mysql','test') and any tables
needed within a testcase ( t/<storage engine>_<test filed>.test )
will be (re)created at the beginning of the test.
5. How to execute the "big" test with many rows per table.
Replace the directories
suite/funcs_1/data and
suite/funcs_1/r
with the appropriate ones for the "big" test.
Set the environment variable NO_REFRESH to a value <> ''.
Start the test for example by
./mysql-test-run.pl --vardir=/dev/shm/var \
--force --suite=funcs_1 --do-test=myisam
All databases and tables will be (re)created by the script
<storage engine>__load.test .
6. I am not sure of the files
./funcs_1/include/create_<whatever>.inc
are in the moment needed. I included them, because I
guess my VIEW testcase example needs them.
I guess the pushed files are far away from being perfect.
It is a 8 hours hack.
Please try them, create missing files and come up with improvements.
Good luck !
Matthias 17.06.2005
===================================================================
Omer 19.06.2005
---------------
1. Changed the structure of the memory_tb3 table to include two
additional column f121, f122. These columns exist for the table in
the other storage engines as TEXT. Since memory does not support
TEXT, Disha did not include them. How ever I am using them in the
Trigger tests so added them to the memory definition as CHAR(50);.
Also modifyed the DataGen_modiy.pl file to account for these two
column when generating the data.
- checked in a new DataGen_modify.pl (create a 'lib' directory
under 'funcs_1').
- checked in a new memory_tb3.txt
2. Added three <storage>_triggers.test files based on Matthias's
structure above.
3. Added three <storage>__triggers.result files
4. Added the Trigger_master.test file in the trigger dierctory
Note: This is not complete and is still under work
5. Created a 'lib' directory and added the DataGen*.pl scripts to it
(exists under the disha suite) but should be here as well).
Omer 19.06.2005
===================================================================
Matthias 12.09.2005
-------------------
Replace the geometry data types by VARBINARY
The removal of the geometry data types was necessary, because the
execution of the funcs_1 testsuite should not depend on the
availability of the geometry feature.
Note: There are servers compiled without the geometry feature.
The columns are not removed, but their data type was changed
VARBINARY. This allows us to omit any changes within the loader
input files or data generation scripts.
The replacement of geometry by VARCHAR allows us to use our
Matthias 12.09.2005
===================================================================
Matthias 14.09.2005
-------------------
The results of the <storage_engine>_views testcases suffer when
executed in "--ps-protocol" mode from the open
Bug#11589: mysqltest, --ps-protocol, strange output,
float/double/real with zerofill .
Implementation of a workaround:
At the beginning of views_master.inc is a variable $have_bug_11589 .
If this varable is set to 1, the ps-protocol will be switched
of for the critical statements.
Matthias 14.09.2005
===================================================================
Carsten 16.09.2005
------------------
1. The results of the datadict_<engine> testcases have been changed in nearly
all occurrencies of --error <n> because now for the INFORMATION_SCHEMA only
the --error 1044 (ERROR 42000: Access denied for user '..' to database
'information_schema') seems to be used.
2. To get identical results when using "--ps-protocol" some SELECTs FROM
information_schema has been wrapped to suppress using ps-protocol because
there are differences.
3. The test using SELECT .. OUTFILE has been disabled due to bug #13202.
4. Fixed datadict_<engine>.result files after the change that added 2 columns to
the VIEWS table (DEFINER varchar(77), SECURITY_TYPE varchar(7)).
===================================================================
Matthias 25.08.2007
-------------------
Data dictionary tests:
Fixes for Bugs 30418,30420,30438,30440
1. Replace error numbers with error names
2. Replace static "InnoDB" (not all time available) used within an
"alter table" by $OTHER_ENGINE_TYPE (set to MEMORY or MyISAM).
Minor adjustment of column data type.
3. Use mysqltest result set sorting in several cases.
4. Avoid any statistics about help tables, because their content
depends on configuration:
developer release - help tables are empty
build release - help tables have content + growing with version
5. Add two help table related tests (one for build, one for developer)
to ensure that informations about help tables within
INFORMATION_SCHEMA.TABLES/STATISTICS are checked.
6. Note about new Bug#30689 at the beginning of the test.
The files with expected results contain incomplete result sets.
7. Fix the NDB variant of the data dictionary test (ndb__datadict) as far as
it was necessary for the bug fixes mentioned above.
General note:
Most INFORMATION_SCHEMA properties (table layout, permissions etc.)
are not affected by our variation of the storage engines except
that some properties of our tables using a specific storage
engine become visible. So it makes sense to decompose
the data dictionary test into a storage engine specific part and
a non storage engine specific part in future.
|
