? Pending

User tests: Successful: Unsuccessful:

avatar alikon
alikon
14 Sep 2019

Summary of Changes

apparently we don't have any issues, but if you look more deep maybe you'll discover that the nested set values (parent_id, lft, rgt) for the #__menu table are incorrect, or at least i believe so, silly me

Testing Instructions

the most easy way i've found need that you run this procedure on your test environment
i've made a gist for you https://gist.github.com/alikon/fc3bdaadcd999a29c9b2b97c00e3214e
just change my4 db prefix with yours
and then compare what is in your #__menu table with tmp_tree table
(e.g)

SELECT `id` , `parent_id`, `lft`, `rgt` FROM `my4_menu` ORDER by `parent_id`

with

select * from `tmp_tree` ORDER by `parent_id`

Expected result

no difference in (id, parent_id, lft, rgt)

Actual result

quite some difference

Additional comment

if and when someone will confirm this the same should be done on the postgresql side which actually have even different values for (lft,rgt) for the same item id ....even without this pr...

avatar alikon alikon - open - 14 Sep 2019
avatar alikon alikon - change - 14 Sep 2019
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 14 Sep 2019
Category SQL Installation
avatar alikon alikon - change - 14 Sep 2019
The description was changed
avatar alikon alikon - edited - 14 Sep 2019
avatar alikon alikon - change - 14 Sep 2019
The description was changed
avatar alikon alikon - edited - 14 Sep 2019
0dae31d 15 Sep 2019 avatar alikon fix
avatar alikon alikon - change - 15 Sep 2019
Labels Added: ?
avatar richard67
richard67 - comment - 15 Sep 2019

@alikon There is something wrong, see following comparison just for the 2nd record, but it applies to all of them except of the 1st which is special:

Current, i.e. without your PR applied:

INSERT INTO `#__menu` (`id`, `menutype`, `title`, `alias`, `note`, `path`, `link`, `type`, `published`, `parent_id`, `level`, `component_id`, `checked_out`, `checked_out_time`, `browserNav`, `access`, `img`, `template_style_id`, `params`, `lft`, `rgt`, `home`, `language`, `client_id`)
SELECT 2, 'main', 'com_banners', 'Banners', '', 'Banners', 'index.php?option=com_banners', 'component', 1, 1, 1, `extension_id`, 0, '0000-00-00 00:00:00', 0, 0, 'class:banners', 0, '', 1, 10, 0, '*', 1 FROM `#__extensions` WHERE `name` = 'com_banners';

New, i.e. with your PR applied:

INSERT INTO `#__menu` (`id`, `menutype`, `title`, `alias`, `note`, `path`, `link`, `type`, `published`, `parent_id`, `level`, `component_id`, `checked_out`, `checked_out_time`, `browserNav`, `access`, `img`, `template_style_id`, `params`, `lft`, `rgt`, `home`, `language`, `client_id`, `publish_up`, `publish_down`) VALUES
...
(2, 'main', 'com_banners', 'Banners', '', 'Banners', 'index.php?option=com_banners', 'component', 1, 1, 1, 4, 0, '0000-00-00 00:00:00', 0, 0, 'class:banners', 0, '', 9, 18, 0, '*', 1, '0000-00-00 00:00:00', '0000-00-00 00:00:00'),

I.e. currently parent_id is selected from the extension_id column of the #__extensions table, but with your PR applied, hard-coded parent_id is used like it was in old times.

Or am I reading something wrong when looking at the changes?

avatar alikon
alikon - comment - 16 Sep 2019

yes right i've just used export cause we are on a install script, but i'll switch back to insert select

avatar alikon alikon - change - 16 Sep 2019
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2019-09-16 16:33:41
Closed_By alikon
avatar alikon alikon - close - 16 Sep 2019
avatar richard67
richard67 - comment - 16 Sep 2019

@alikon Why closed? Will you make a new PR for that? Or has it meanwhile been fixed by someone else?

avatar alikon
alikon - comment - 16 Sep 2019

there is no added value in fixing the install script only... when some strange things may happen during some crazy update script... i'm re-thinking .... after reading this #26289 (comment)

avatar richard67
richard67 - comment - 16 Sep 2019

I see. Makes sense. Maybe we should really call a rebuild function (if there is one) after each update or database fix?

avatar alikon
alikon - comment - 16 Sep 2019

more i look at the updates script...more i think we are doing it wrong....still trying to understand why we have 3.8.x or 3.9.x sql update script when it is supposed to upgrade from 3.10 only....

avatar richard67
richard67 - comment - 16 Sep 2019

Maybe @wilsonge knows that, why we have update scripts 2.5 to 3.9 in the 4.0-dev branch.

avatar wilsonge
wilsonge - comment - 17 Sep 2019

3.8 can be removed. I'm leaving 3.9 for now because i don't have 3.10-dev merged into 4.0-dev - so i'm testing the 3.x upgrade path from 3.9 for now. Once I've got 3.10-dev in sync with 4.0-dev then we'll remove the 3.9 upgrade files too

We don't have the 2.5-3.7 files @richard67 ;)

avatar richard67
richard67 - comment - 17 Sep 2019

@wilsonge It seems it's a while ago I've looked on the update sql scripts ;-)

Add a Comment

Login with GitHub to post a comment