View Issue Details

IDProjectCategoryView StatusLast Update
2025RackTablesdefaultpublic2021-05-23 23:47
ReporterFGu Assigned Toinfrastation  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product Version0.21.5 
Summary2025: Upgrade 0.21.1 -> 0.21.5 fails upgrade query in 0.21.2
DescriptionSimilar as https://bugs.racktables.org/view.php?id=1999 but with different ID

The following queries failed:

INSERT INTO Chapter (`id`, `sticky`, `name`) VALUES (39,'no','UPS models') -- Duplicate entry '39' for key 'PRIMARY'
INSERT INTO AttributeMap (`objtype_id`,`attr_id`,`chapter_id`) VALUES (12,2,39) -- Duplicate entry '12-2' for key 'objtype_id'

tried solution from Bug#1999, didn't resolve the issue
Steps To ReproduceInstall 0.21.1
Upgrade to 0.21.5
Additional InformationBefore upgrade:
 SELECT * FROM Chapter WHERE name = 'UPS models';
Empty set (0.01 sec)

After upgrade:
 SELECT * FROM Chapter WHERE name = 'UPS models';
+----+--------+------------+
| id | sticky | name |
+----+--------+------------+
| 39 | no | UPS models |
+----+--------+------------+


TagsNo tags attached.

Activities

infrastation

infrastation

2021-05-07 13:30

administrator   ~0004283

When exactly does the error happen?
FGu

FGu

2021-05-07 14:28

reporter   ~0004285

right during the upgrade
upgrade.PNG (40,911 bytes)   
upgrade.PNG (40,911 bytes)   
infrastation

infrastation

2021-05-07 20:45

administrator   ~0004287

Thank you for confirming. This issue is different from 1999, the only similarity seems to be some local custom backporting of database changes that were made in post-0.21.1 releases.

If you get the same result as below, these two error messages during the upgrade do not require any more troubleshooting.
mysql> SELECT chapter_id FROM AttributeMap WHERE objtype_id = 12 AND attr_id = 2;
+------------+
| chapter_id |
+------------+
|         39 |
+------------+
1 row in set (0.00 sec)
FGu

FGu

2021-05-10 09:16

reporter   ~0004289

Unfortunately not:
 SELECT chapter_id FROM AttributeMap WHERE objtype_id = 12 AND attr_id = 2;
+------------+
| chapter_id |
+------------+
| 10049 |
+------------+
1 row in set (0.01 sec)

Running the same statements you recommended in 1999 also didn't fix the issue:
UPDATE Chapter SET name = 'UPS models custom' WHERE id = 10049;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0

INSERT INTO Chapter (`id`, `sticky`, `name`) VALUES (39,'no','UPS models');
ERROR 1062 (23000): Duplicate entry '39' for key 'PRIMARY'

The database is rolled back to 0.21.1 again now so we can start all over again
infrastation

infrastation

2021-05-10 19:18

administrator   ~0004291

Thank you. One of the things I do not understand is what the pre-existing chapter 39 is. Please examine the output of these queries and confirm whether it stands for UPS hardware (you do not need to post the results here if you do not want to):
mysql> SELECT name from Chapter WHERE id = 39;
mysql> SELECT dict_key, dict_value FROM Dictionary WHERE chapter_id = 39;
FGu

FGu

2021-05-11 07:03

reporter   ~0004293

this is pre-upgrade:

SELECT name from Chapter WHERE id = 39;
Empty set (0.00 sec)

SELECT dict_key, dict_value FROM Dictionary WHERE chapter_id = 39;
Empty set (0.00 sec)

so nothing at all
infrastation

infrastation

2021-05-11 19:24

administrator   ~0004295

This is an unexpected result: you should not be getting the first error from the "0.21.2" batch in the first place.

Anyway, based on you latest comments please find the next steps to try below:

0. Be at the same point as the backup (before the upgrade).
1. Upgrade to 0.21.5 and confirm that the fist error from the problem description does not appear, and the second does.
2. Run the script from bug 1999 with CUSTOM_CID=10049 and confirm it does not print any errors.

Let me know how it went.
FGu

FGu

2021-05-12 08:25

reporter   ~0004297

0 - done
1 - interestingly enough only the second error appeared even though the backup was the same as before the initial upgrade (screenshots were taken after a restore to confirm this bug wasn't a one time only thing). Anyway only the second line appeared now
2 - the script ran without errors but didn't print any output either

if you want we can always have a session together
infrastation

infrastation

2021-05-12 11:36

administrator   ~0004299

Then to me it sounds like your database is consistent now and at 0.21.5.

The dictionary should have exactly one "UPS models" chapter, if entries in the latter display any references to objects, you can look at the objects to confirm the UPS attribute has the expected values, and to apply any changes required. Also in the reports you can check that "data integrity" does not raise any issues.

But other than that, the original problem looks solved. Please confirm before closing.
FGu

FGu

2021-05-17 09:45

reporter   ~0004301

sorry for the late reply, I didn't have time to check things in the last couple of days.

I can confirm there is only one chapter of "UPS models" and the expected attributes match.

The data integrity report currently shows the attached issues for the test system, our productive currently only show the Foreign Keys but I suspect that's because of the link management plugin.
However both of them don't seem to indicate any issues with the UPS systems so I don't think it's related to the initial bug report.

If you can point me in the right direction to solve these issues and learn how to interpret the data integrity report I'd really appreciate any input.
Thank you!
integrity.PNG (8,844 bytes)   
integrity.PNG (8,844 bytes)   
FGu

FGu

2021-05-17 09:47

reporter   ~0004303

just to add: the prod system is still on 0.21.1 - still need to perform the restore to verify the missing triggers are not caused by the upgrade
infrastation

infrastation

2021-05-23 23:47

administrator   ~0004305

Excuse me, I was busy. Thank you for confirming.

The unknown foreign keys indeed belong to the link management plugin, so these are not a problem.

The missing triggers are a problem. All four were introduced in release 0.20.7 (2014-03-03), so if that failed at the time, the database might have accumulated some inconsistent rows as a consequence. Some of these inconsistent rows would be highlighted in the integrity report if that was the case, but it is difficult to tell quickly if the report fully checks all related cases. In other words, lack of other warnings does not necessarily mean lack of associated issues.

Regarding the best way of resolving this, you can learn the schema and the code if you want to do that yourself, but it would take quite a bit of work. I might be able to confirm the data consistency later, but please do not count on it. In any case, the missing triggers problem is not related to the original request and should be handled separately, so I am closing this request as resolved.

Issue History

Date Modified Username Field Change
2021-05-07 11:15 FGu New Issue
2021-05-07 13:30 infrastation Note Added: 0004283
2021-05-07 14:28 FGu Note Added: 0004285
2021-05-07 14:28 FGu File Added: upgrade.PNG
2021-05-07 20:45 infrastation Note Added: 0004287
2021-05-10 09:16 FGu Note Added: 0004289
2021-05-10 19:18 infrastation Note Added: 0004291
2021-05-10 19:18 infrastation Assigned To => infrastation
2021-05-10 19:18 infrastation Status new => assigned
2021-05-11 07:03 FGu Note Added: 0004293
2021-05-11 19:24 infrastation Note Added: 0004295
2021-05-12 08:25 FGu Note Added: 0004297
2021-05-12 11:36 infrastation Note Added: 0004299
2021-05-17 09:45 FGu Note Added: 0004301
2021-05-17 09:45 FGu File Added: integrity.PNG
2021-05-17 09:47 FGu Note Added: 0004303
2021-05-23 23:47 infrastation Note Added: 0004305
2021-05-23 23:47 infrastation Status assigned => closed
2021-05-23 23:47 infrastation Resolution open => no change required