Skip to content

Conversation

@richard67
Copy link
Member

@richard67 richard67 commented Oct 4, 2019

Pull Request for Issue #24535 (part).

Summary of Changes

This PR fixes all datetime columns of the com_categories database table #__categories so there will not be any Invalid value '0000-00-00 00:00:00' for datetime error anymore on MySQL 5.7 or later when strict mode is enabled.

Similar to my other PR's for the datetime/timestamp columns of other components, this PR makes column checked_out_time nullable and have default value NULL.

In addition this PR removes the default values from columns created_time and modified_time. This will enforce to insert new records with values for these columns being provided and throw an SQL error if some of these values is not specified, i.e. such errors will not be hidden anymore.

Old data will be updated as little as possible. The created_time column will be not touched at all. We can assume that for core components there is no data with values '0000-00-00 00:00:00' on MySQL or '1970-01-01 00:00:00' on PostgreSQL, and data created by 3rd party components should not be modified. The modified_time column will be set to the value of the created_time column only if it has value '0000-00-00 00:00:00' on MySQL or '1970-01-01 00:00:00' on PostgreSQL. Our PHP already sets the modified time to the created time when saving new records, i.e. modified = created means never modified.

Testing Instructions

Testers please report back the database kind (MySQL or PostgreSQL) on which you have tested.

If you have both MySQL and PostgreSQL, please test on both if possible.

Test 1: New installation

  1. Apply the patch on a clean 4.0-dev branch using git or merging manually, or apply it on an installation of current 4.0-dev using patchtester.
  2. If used patchtester on an existing installation in step 1, delete file configuration.php and delete all Joomla database tables in PhpMyAdmin or PhpPgAdmin (depending on your database type).
  3. Do a new installation, login to backend, confirm the statistics dialog, go to global config and set error reporting to maximum or development in server settings.
  4. Play around with categories, create some, modify some, filter in the list display, ...
  5. After any action, check in your database the relevant datetime/timestamp without timezone columns.

Result: See section "Expected result" below.

Test 2: Update sql script

  1. Install a clean clean 4.0-dev, login to backend, confirm the statistics dialog, go to global config and set error reporting to maximum or development in server settings.
  2. Apply the changes from this PR e.g. manually or with patch tester.
  3. Open PhpMyAdmin or PhpPgAdmin (depending on your database type), select your database and then go to the SQL command input.
  4. On MySQL copy the first line of file installation/sql/mysql/joomla.sql into the SQL command window but don't execute the commands yet:
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";

This switches off strict mode to the SQL will run on MySQL 5.7 or later.

  1. Copy the content of file administrator/components/com_admin/sql/updates/mysql/4.0.0-2019-09-29.sql or administrator/components/com_admin/sql/updates/postgresql/4.0.0-2019-09-29.sql (depending on your database type) into the SQL command window, in case of MySQL below the previously pasted commands, but don't execute the commands yet.
  2. Replace #__ by your database prefix in the SQL statements pasted before in the SQL input window.
  3. Put the cursor to the beginning of the 1st SQL statement in the SQL input window and now execute all SQL commands.
  4. Play around with categories, create some, modify some, filter in the list display, ...
  5. After any action, check in your database the relevant datetime/timestamp without timezone columns.

Result: See section "Expected result" below.

Expected result

New Installation

Categories work as well as without this PR. In a MySQL database there are no columns of data type datetime having value '0000-00-00 00:00:00' in table #__categories, and there is no invalid default value anymore in MySQL >= 5.7 with strict mode on. On PostgreSQL there are no columns of data type timestamp without time zone having value '0000-00-00 00:00:00' in this table.

There is one exception: When checking in a category using com_checkin, the checked_out_time is set to '0000-00-00 00:00:00' on MySQL and '1970-01-01 00:00:00' on PosgreSQL. This will be changed with a separate, future PR for com_checkin. Checking in an item with the lock icon in list display works, i.e. there checked_out_time is set to NULL.

Update sql script

The statements are processed without error. The expected result is the same as for a new installation.

Actual result

New Installation

On MySQL same as expected, but the default value of database columns of data type datetime having value '0000-00-00 00:00:00' in table #__categories is invalid in MySQL >= 5.7 with strict mode on, and there might be values '0000-00-00 00:00:00'. On postgreSQL same as expected, but there might be values '1970-01-01 00:00:00' in this table.

Documentation Changes Required

Maybe core developer docs and extension developer docs should be updated to encourage them not to use '0000-00-00 00:00:00' on MySQL anymore but use real NULL and not abuse '1970-01-01 00:00:00' on PostgreSQL as a speudo null date anymore and use real NULL values also there.

@richard67 richard67 changed the title [4.0] [WiP] [com_categories] Fix default value for not nullable datetime columns and make some nullable [4.0] [com_categories] Fix default value for not nullable datetime columns and make some nullable Oct 6, 2019
@richard67 richard67 marked this pull request as ready for review October 6, 2019 13:20
@wilsonge
Copy link
Contributor

wilsonge commented Oct 9, 2019

@Bakual are you able to test this with your sermon component - I want to make sure this isn't affecting anything in 3rd party components

@Bakual
Copy link
Contributor

Bakual commented Oct 15, 2019

@wilsonge I don't see anything which could possibly break my SermonSpeaker component.
All it does is make the #__categories checked_out column nullable (which usually 3rd parties don't care about).
And it changes the modified column to always contain a value. Again a column I don't care about in my 3rd party code.

So from my point of view this should be fine.

@Bakual Bakual self-requested a review October 15, 2019 18:13
@wilsonge wilsonge merged commit ee36dda into joomla:4.0-dev Oct 16, 2019
@wilsonge
Copy link
Contributor

Thanks!

@wilsonge wilsonge added this to the Joomla 4.0 milestone Oct 16, 2019
@richard67 richard67 deleted the 4.0-dev-datetime-default-com-categories branch October 16, 2019 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants