View Issue Details

IDProjectCategoryView StatusLast Update
1855RackTablesdefaultpublic2018-11-07 00:19
Reporternetniv Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product Version0.21.0 
Summary1855: Upgrade to 0.21.2 fails due to reload of dictionary before chapter insertition
DescriptionWhen upgrading from a version more than one away from 0.21.2, the upgrade fails because the dictionary appears to be being reloaded before Chapter ID 39 has been insert. This is because during the upgrade path from 0.21.0, it attempts to upgrade to 0.21.1. However, the $dictionary variable does not hold any version metadata and so when reloadDictionary is called, it simply tries to insert the two APC dictionary entries (truncated lines below):


        3689 => array ('chapter_id' => 39, 'dict_value' => '[[APC%GPASS%SMT1500RMI2U
        3690 => array ('chapter_id' => 39, 'dict_value' => '[[APC%GPASS%SMT1500RMI2UNC

As a result of this, I'm not sure that the schema is properly upgraded.
Steps To Reproduce1. Install 0.21.0
2. Upgrade directly to 0.21.2
Additional InformationINSERT INTO Dictionary (dict_key, chapter_id, dict_value, dict_sticky) VALUES (3689, 39, '[[APC%GPASS%SMT1500RMI2U | http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=SMT1500RMI2U]]', 'yes'),
(3690, 39, '[[APC%GPASS%SMT1500RMI2UNC | http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=SMT1500RMI2UNC]]', 'yes'),
(3691, 12, '[[NETGEAR%GPASS%GS108 | https://www.netgear.com/business/products/switches/unmanaged/GS108.aspx]]', 'yes'),
(3692, 12, '[[NETGEAR%GPASS%GS105 | https://www.netgear.com/business/products/switches/unmanaged/GS105.aspx]]', 'yes'),
(3693, 13, '[[PROXMOX%GSKIP%Proxmox VE 3.4 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_3.4]]', 'yes'),
(3694, 13, '[[PROXMOX%GSKIP%Proxmox VE 4.0 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.0]]', 'yes'),
(3695, 13, '[[PROXMOX%GSKIP%Proxmox VE 4.1 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.1]]', 'yes'),
(3696, 13, '[[PROXMOX%GSKIP%Proxmox VE 4.2 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.2]]', 'yes'),
(3697, 13, '[[PROXMOX%GSKIP%Proxmox VE 4.3 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.3]]', 'yes'),
(3698, 13, '[[PROXMOX%GSKIP%Proxmox VE 4.4 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_4.4]]', 'yes'),
(3699, 13, '[[PROXMOX%GSKIP%Proxmox VE 5.0 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_5.0]]', 'yes'),
(3700, 13, '[[PROXMOX%GSKIP%Proxmox VE 5.1 | http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_5.1]]', 'yes'),
(3701, 12, '[[TP-Link%GPASS%T1600G-18TS | https://www.tp-link.com/en/products/details/cat-40_T1600G-18TS.html]]', 'yes'),
(3702, 27, '[[Raritan%GPASS%PX3-5514U | http://cdn.raritan.com/product-selector/pdus/PX3-5514U/MPX3-5514U.pdf]]', 'yes'),
(3703, 12, '[[HP Aruba%GPASS%3810M 16SFP+ 2-slot (JL075A) | http://duckduckgo.com/?q=JL075A+manual ]]', 'yes'),
(3704, 13, 'VMWare Hypervisor%GSKIP%VMware ESXi 6.5', 'yes'),
(3705, 17, '[[ Fortinet%GPASS%Fortigate 600D | http://www.fortinet.com/content/dam/fortinet/assets/data-sheets/FortiGate_600D.pdf ]]', 'yes'),
(3706, 13, 'Ubuntu%GSKIP%Ubuntu 18.04 LTS', 'yes'),
(3707, 12, 'MikroTik%GPASS%CRS328-4C-20S-4S+RM', 'yes'),
(3708, 12, 'MikroTik%GPASS%CRS328-24P-4S+RM', 'yes'),
(3709, 13, '[[Debian%GSKIP%Debian 9 (Stretch) | http://debian.org/releases/stretch/]]', 'yes'),
(3710, 12, 'Arista%GPASS%7170-32C', 'yes'),
(3711, 12, 'Arista%GPASS%7170-64C', 'yes'),
(3712, 12, 'Arista%GPASS%7060SX2-48YC6', 'yes'),
(3713, 12, 'Arista%GPASS%7260CX3-64', 'yes')
-- Cannot add or update a child row: a foreign key constraint fails (`racktables_chris`.`Dictionary`, CONSTRAINT `Dictionary-FK-chapter_id` FOREIGN KEY (`chapter_id`) REFERENCES `Chapter` (`id`))
TagsNo tags attached.

Activities

netniv

netniv

2018-10-23 11:31

reporter   ~0003829

Firstly, I should have noted above, that this is using a clone of the GitHub code: c92c427b - (HEAD -> master, origin/master, origin/HEAD) upgrade CodeMirror from 5.39.0 to 5.40.2 (5 weeks ago)

Secondly, to work around this, one must manually insert the chapter first:

INSERT INTO Chapter (`id`, `sticky`, `name`) VALUES (39,'no','UPS models')

This prevents the error and upgrade to 0.21.1 is successful
netniv

netniv

2018-10-23 18:12

reporter   ~0003833

Further more, when I did the above, the upgrade said all was complete, come back later. However, then entering the site it crashes due to a missing column which was added in 0.21.2. Since the CODE_VERSION was 0.21.1, this fails to upgrade correctly. Modifying the CODE_VERSION corrects this.
infrastation

infrastation

2018-10-30 23:44

administrator   ~0003837

This is the expected behaviour -- the master branch is not a release so if you decide to use it you become responsible for keeping the database up to date with the code (through monitoring the queries that appear in upgrade.php for the not yet released version and applying them to the live database). See also my recent comment in pull request 228. Closing.
netniv

netniv

2018-10-31 00:16

reporter   ~0003839

Whilst the versioning may be expected, the dictionary/chapter error should be rectified if it has not already been done. It will cause upgrade issues from what I have seen.
infrastation

infrastation

2018-10-31 09:34

administrator   ~0003841

If you study the 0.21.2 section in upgrade.php, you will see why the original issue happens with a git repository clone and why it will not happen during a normal upgrade from 0.21.1 to 0.20.2 when 0.20.2 is available as a release. The dictionary is reloaded at the very end of an upgrade, after any additional chapters have been added.
netniv

netniv

2018-11-01 13:38

reporter   ~0003843

From what I saw, yes, that would work. But, if you are upgrading from say 0.21.0 to 0.21.2, or 0.20.x to 0.21.2, then the chapter wouldn't have been added yet, but the dictionary would have been loaded. In fact, that's not just from what I read, but from what I experienced.
infrastation

infrastation

2018-11-01 22:30

administrator   ~0003845

From your comments it looks like you confuse an existing RackTables release with a branch git repository clone between releases. If you are interested in the differences between the two, feel free to study the previous comments with attention and to make some research in the source code as suggested.

Whether you do that or not, to the best of my knowledge there are measures in place to make sure the future release 0.21.2 (when it comes into existence in future) will not expose the problem originally stated in this bug description.

In case I still miss something important, feel free to provide better formulated steps to reproduce and/or to suggest a specific patch that addresses the issue.

Thank you.

Issue History

Date Modified Username Field Change
2018-10-23 11:25 netniv New Issue
2018-10-23 11:31 netniv Note Added: 0003829
2018-10-23 18:12 netniv Note Added: 0003833
2018-10-30 23:44 infrastation Status new => closed
2018-10-30 23:44 infrastation Resolution open => no change required
2018-10-30 23:44 infrastation Note Added: 0003837
2018-10-31 00:16 netniv Status closed => feedback
2018-10-31 00:16 netniv Resolution no change required => reopened
2018-10-31 00:16 netniv Note Added: 0003839
2018-10-31 09:34 infrastation Note Added: 0003841
2018-11-01 13:38 netniv Note Added: 0003843
2018-11-01 13:38 netniv Status feedback => new
2018-11-01 22:30 infrastation Note Added: 0003845
2018-11-07 00:19 infrastation Status new => closed
2018-11-07 00:19 infrastation Resolution reopened => no change required