mirror of
https://github.com/gosticks/wordpress-develop.git
synced 2025-10-16 12:05:38 +00:00
37368555a5
MySQL 8.0.17 deprecated the display width attribute for integer data types: > As of MySQL 8.0.17, the `ZEROFILL` attribute is deprecated for numeric data types, as is the display width attribute for integer data types. You should expect support for `ZEROFILL` and display widths for integer data types to be removed in a future version of MySQL. Consider using an alternative means of producing the effect of these attributes. For example, applications can use the `LPAD()` function to zero-pad numbers up to the desired width, or they can store the formatted numbers in `CHAR` columns. In practice, this means that display width is removed for integer types when creating a table: * `BIGINT(20)` → `BIGINT` * `INT(11)` → `INT` * `MEDIUMINT(9)` → `MEDIUMINT` * `SMALLINT(6)` → `SMALLINT` * `TINYINT(4)` → `TINYINT` Note: This only applies specifically to MySQL 8.0.17 or later. In MariaDB, display width for integer types is still available and expected. This commit ensures that `dbDelta()`, which relies on the `DESCRIBE` SQL command to get the existing table structure and field types, when running on MySQL 8.0.17 or later, does not unnecessarily attempt to convert `BIGINT` fields back to `BIGINT(20)`, `INT` back to `INT(11)`, etc. When comparing the field type in the query with the existing field type, if display width is the only difference, it can be safely ignored to match MySQL behavior. The change is covered by existing `dbDelta()` unit tests: * A test for not altering `wp_get_db_schema()` queries on an existing install using MySQL 8.0.17+ now passes. * More than twenty tests which previously failed on PHP 8.0.x + MariaDB due to incorrect expectations, caused by MariaDB version reporting not being consistent between PHP versions, now pass. References: * [https://dev.mysql.com/doc/refman/8.0/en/numeric-type-attributes.html MySQL: Nymeric Type Attributes] * [https://mariadb.com/kb/en/data-types-numeric-data-types/ MariaDB: Numeric Data Types] Follow-up to [1575], [18899], [37525], [47183], [47184]. Props SergeyBiryukov, pbearne, leewillis77, JavierCasares, desrosj, costdev, johnbillion. Fixes #49364. See #51740. git-svn-id: https://develop.svn.wordpress.org/trunk@53897 602fd350-edb4-49c9-b593-d223f7449a82 |
||
|---|---|---|
| .. | ||
| data | ||
| includes | ||
| tests | ||
| multisite.xml | ||
| README.txt | ||
| wp-mail-real-test.php | ||
The short version:
1. Create a clean MySQL database and user. DO NOT USE AN EXISTING DATABASE or you will lose data, guaranteed.
2. Copy wp-tests-config-sample.php to wp-tests-config.php, edit it and include your database name/user/password.
3. $ svn up
4. Run the tests from the "trunk" directory:
To execute a particular test:
$ phpunit tests/phpunit/tests/test_case.php
To execute all tests:
$ phpunit
Notes:
Test cases live in the 'tests' subdirectory. All files in that directory will be included by default. Extend the WP_UnitTestCase class to ensure your test is run.
phpunit will initialize and install a (more or less) complete running copy of WordPress each time it is run. This makes it possible to run functional interface and module tests against a fully working database and codebase, as opposed to pure unit tests with mock objects and stubs. Pure unit tests may be used also, of course.
Changes to the test database will be rolled back as tests are finished, to ensure a clean start next time the tests are run.
phpunit is intended to run at the command line, not via a web server.