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_idis selected from theextension_idcolumn of the#__extensionstable, but with your PR applied, hard-codedparent_idis used like it was in old times.Or am I reading something wrong when looking at the changes?