User tests: Successful: Unsuccessful:
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
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`
no difference in (id, parent_id, lft, rgt)
quite some difference
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...
Status | New | ⇒ | Pending |
Category | ⇒ | SQL Installation |
Labels |
Added:
?
|
yes right i've just used export cause we are on a install script, but i'll switch back to insert select
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-09-16 16:33:41 |
Closed_By | ⇒ | alikon |
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)
I see. Makes sense. Maybe we should really call a rebuild function (if there is one) after each update or database fix?
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....
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 ;)
@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:
New, i.e. with your PR applied:
I.e. currently
parent_id
is selected from theextension_id
column of the#__extensions
table, but with your PR applied, hard-codedparent_id
is used like it was in old times.Or am I reading something wrong when looking at the changes?