[4.0] Cleanup previous date time queries and implement new ones for com_content

[wilsonge]

• Cleans up queries from previous attempts to not check for 1000-01-01 00:00:00. All our values here come from PHP - so they're going to use our null date (always 0000). Has the side effect of this being parseable by the schema checker
• Implements from scratch in com_content including the JTable change required

// cc @alikon @richard67

[richard67]

Tomorrow when I’m back to my PC first thing I’ll do is review and test. First look on my mobile phone looks good.

[richard67]

@wilsonge What did you mean with "Has the side effect of this being parseable by the schema checker"? The update statements? Those are DML (data manipulation language part of SQL) and so still not parsed by the database schema checker/fixer.

[twister65]

In table #__content, the column checked_out_time is NULL instead of 1970-01-01 00:00:00 (PostgreSQL).
But publish_up, publish_downcolumns have a null date value.

[richard67]

@twister65 As far as I understand this PR, it is desired that each of these 3 columns checked_out_time, publish_up and publish_down of table #__content shall be nullable and that for records where such a column has value '1970-01-01 00:00:00' it is changed to NULL by running the sql commands in file administrator/components/com_admin/sql/updates/postgresql/4.0.0-2019-09-14.sql in PhpPgAdmin. Did you do it that way, and did you have for each column an example which should have value NULL aftert that?

[twister65]

I applied the patch with patchtester, and click on Fix in the system -> database.
After that, I created a new unpublished article.
I can see in the database that publish_up and publish_down columns have a null date value, but not ˋchecked_out_timeˋ which is NULL.

[richard67]

"fix" button does only run DDL (data definition language) part of SQL language, i.e. ALTER TABLE, DROP TABLE, CREATE TABLE, but not DML (data manipulation language), i.e. INSERT, UPDATE, DELETE, so the Fix button only changes default values of columns but does not run the update statements for changing values of existing records.

One of the secrets of the Fixer 😄

[richard67]

P.S.: You have to run the update statements of the update sql scripts in PhpPgAdmin.

[richard67]

P.P.S: I.e. DDL changes data structure, DML changes data content. DB checker/fixer can only handle DDL, the DML statements are reported as "xxx statements did not alter structure and so were skipped" (or so).

[twister65]

I also applied this patch in joomla.sql before a new installation with the same result.

[richard67]

In table #__content, the column checked_out_time is NULL instead of 1970-01-01 00:00:00 (PostgreSQL).

@twister65 To be honest, I did not fully understand your comment anyway. Do you mean the default value of column checked_out_time is NULL? Or do you mean the value for some records from some sample data? If the latter: This PR does not change the sample data values.

It works fine with columns publish_up and publish_down.

And what did you mean with that? What works? I would expect them to be null and have default value of null, too.

Maybe you could explain to mea bit more detailled? I really want to be sure I don't understand anything wrong. I could not test this PR myself yet on PostgreSQL.

[twister65]

I mean the values of my new unpublished article created. In the table structure, these three timestamp columns have a default value of NULL.
Therefore, these three columns must be NULL for a new unpublished article.

[twister65]

Sorry, I misunderstand this PR, I thought there was a parser / checker in the code behind for null date values.

[richard67]

An update container based on nightly build of today + this PR applied for testing update of 3.9.11 or current staging to 4.0-alpha12-dev using the "Upload & Install" tab of the Joomla Update Component can be found here: Obsolete link removed

[richard67]

@wilsonge I've just tested new install on MySQL. Com_content columns are like they should regarding definition. When I create a new article in backend, checked out time column has value null, but puplished up and down are still inserted with the '0000-00-00...' datetime value. When I change this to null in PhpMyAdmin, all works fine, i.e. I can set publish up and down, change article status and so on, all fine it seems. So it seems that it needs only to change some code for inserting new articles to get rid of the '0000-00-00...' for the nullable columns (not nullable ones are other thing). Maybe we can take that from @Hackwar 's PR #25760 . SHall I make a PR to your branch, George?

[richard67]

@wilsonge For saving new articles with null value for all nullable columns, i.e. also publish up and down, see wilsonge#38. In addition it also sets the modified column to the created value if modified is null.

[SharkyKZ]

In addition it also sets the modified column to the created value if modified is null.

@richard67 Shouldn't modified date be nullable?

[richard67]

@SharkyKZ No, we decided to have it not nullable, and equal to created date for new records.

[SharkyKZ]

What's the reasoning behind this?

[richard67]

Was George's idea, maybe for BC reasons or for versioning.

[SharkyKZ]

By the way don't we need to update the values in UCM content table?

[alikon]

i think so

[richard67]

@alikon @Quy @SharkyKZ @twister65 and all others: More testers are needed. Instructions you can find in my test result above. I've updated the zip package for update test and the link to it so it is like current 4.0-dev plus this PR.

[wilsonge]

Thankyou for all you've done to help with on this @richard67 <3

[alikon]

I have tested this item ✅ successfully on f05c532

on mysql 8.0.16-0ubuntu3

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26295.}

[alikon]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26295.}

[Quy]

Please commit the 2 suggested changes.

[richard67]

@Quy The ucm_content table is updated for each component in the particular update sql script, see e.g. the other update sql in this PR.

[richard67]

@wilsonge I guess @Quy means the 2 changes in code comments. Other comments are clarified, I thinks.

[wilsonge]

Thanks @richard67 !

[richard67]

Thanks @wilsonge .. it was team work.