[#28385] - [4.0] Updates from 3.10 failing
- Closed
- 19 Mar 2020
- Urgent
- Build: staging
- # 28385
Steps to reproduce the issue
- Install a fresh copy of 3.10 nightly (both with and without testing sample data)
- Go to the Joomla Update Component component config and set the URL to custom (https://update.joomla.org/core/nightlies/next_major_list.xml) and the status to development.
- Update to Joomla 4.0
- After files are successfully written and you re-authenticate (with a known issue about incorrect templates warnings when you do this) then you'll get a sql error:
JInstaller: :Install: Error SQL Column 'checked_out_time' cannot be null
Obviously we shouldn't get this failed SQL error. As a result pretty much the entire J4 Schema migrations fail to run so you get empty system dashboards so basically a total disaster :)
System information (as much as possible)
OSX, MySQL:
mysql --version
mysql Ver 15.1 Distrib 10.3.16-MariaDB, for osx10.14 (x86_64) using readline 5.1
joomla-cms-bot
- | Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
Ah I See, is in the error log.
jwaisner
- | Priority | Medium | ⇒ | Urgent |
| Labels |
Removed:
?
|
||
| Status | New | ⇒ | Confirmed |
| Labels |
Added:
?
|
||
| Labels |
Removed:
?
|
||
| Title |
|
||||||
Can be reproduced also with staging or 3.9.16 when using upload&update.
Same on a clean 3.10-dev branch without any sample data ... joomlaupdate log file shows as last statement:
CREATE TABLE IF NOT EXISTS #__webauthn_credentials( id VARCHAR(. from file 4.0.0-2019-07-02.
Am investigating and will try to solve it.
I've found the reason for the problem.
The reason is the webauthn update sql script 4.0.0-2019-07-02.sql uses already NULL for the checked_out_time column when inserting its record into the #__extensions table, but this column in this table is changed to allow real NULL values in script 4.0.0-2019-10-06.sql, which runs after the previously mentioned one on update ;-)
It's the same for MySQL and PostgreSQL.
Closing as having PR.
| Status | Confirmed | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-03-18 18:37:46 |
| Closed_By | ⇒ | richard67 |
| Labels |
Removed:
?
|
||
| Status | Closed | ⇒ | New |
| Closed_Date | 2020-03-18 18:37:46 | ⇒ | |
| Closed_By | richard67 | ⇒ |
Still happening on latest nightly with your change :(
| Labels |
Added:
?
|
||
Added back Beta Blocker label since it was removed when the issue was closed.
What is strange: When I've tested yesterday with MySQL 8 and PostgreSQL 11 and my PR applied, it worked. And I've just checked the update package from last nightly build: It contains the changes from my PR.
Still can't reproduce that anymore since my PR has been merged, neither with MySQL 5.7 now with MySQL 8, using the official nightly build download URL as custom URL, as described in the description of this issue.
There is another issue not related to this one here, error related to removed fields plugin, shown one time after first login to backend, but SQL all went fine. For the fields issue I'll make new issue or PR soon.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-03-19 22:54:24 |
| Closed_By | ⇒ | wilsonge |
| Labels |
Removed:
?
|
||
Maybe it needs the same check as done with PR #27228 for the core_checked_out_time column of the ucm content table also for the checked_out_time columns of any table where we have this, i.e. convert emptry strings to old (pseudo-) null dates in the same update sql script where we modify that column to accept real null values, just before the corresponding alter table modify statement?