diff options
Diffstat (limited to 'mysql-test/suite/funcs_1/README.txt')
| -rw-r--r-- | mysql-test/suite/funcs_1/README.txt | 185 |
1 files changed, 45 insertions, 140 deletions
diff --git a/mysql-test/suite/funcs_1/README.txt b/mysql-test/suite/funcs_1/README.txt index e32299dac2d..7e98d1bc117 100644 --- a/mysql-test/suite/funcs_1/README.txt +++ b/mysql-test/suite/funcs_1/README.txt @@ -1,141 +1,46 @@ -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. +2008-02-29 Matthias Leich +========================= + +1. The testsuite "funcs_1" is mostly intended for additional (compared + to the common regression tests stored in mysql-test/t) checks + of features (VIEWS, INFORMATION_SCHEMA, STORED PROCEDURES,...) + introduced with MySQL 5.0. + +2. There were some extensions of this suite when new information_schema + views were introduced. But in most cases the tests for these views + were stored within the regression testsuite (mysql-test/t). + + INFORMATION_SCHEMA views introduced with MySQL 5.1 + ================================================== + ENGINES (partially tested here) + EVENTS (partially tested here) + FILES + GLOBAL_STATUS + GLOBAL_VARIABLES + PARTITIONS + PLUGINS + PROCESSLIST (full tested here) + PROFILING + REFERENTIAL_CONSTRAINTS + SESSION_STATUS + SESSION_VARIABLES + +3. Some hints: + - SHOW TABLES ... LIKE '<pattern>' + does a case sensitive comparison between the tablename and + the pattern. + The names of the tables within the informationschema are in uppercase. + So please use something like + SHOW TABLES FOR information_schema LIKE 'TABLES' + when you intend to get the same non empty result set on OS with and + without case sensitive filesystems and default configuration. + - The name of the data dictionary is 'information_schema' (lowercase). + - Server on OS with filesystem with case sensitive filenames + (= The files 'abc' and 'Abc' can coexist.) + + default configuration + Example of behaviour: + DROP DATABASE information_schema; + ERROR 42000: Access denied for user ... to database 'information_schema' + DROP DATABASE INFORMATION_SCHEMA; + ERROR 42000: Access denied for user ... to database 'INFORMATION_SCHEMA' -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. |