Bug 30951 - Duplicate entry 'ar' for key 'PRIMARY'
Summary: Duplicate entry 'ar' for key 'PRIMARY'
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: 22.05
Hardware: All All
: P5 - low critical (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 29605
Blocks:
  Show dependency treegraph
 
Reported: 2022-06-13 10:14 UTC by victor
Modified: 2022-08-01 14:32 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description victor 2022-06-13 10:14:11 UTC
In Ubuntu 20.04.4 LTS
mysql  Ver 15.1 Distrib 10.4.14-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

ERROR
koha-upgrade-schema library
Upgrade to 21.12.00.013  [19:25:20]: Bug 29605 - Resync DB structure for existing installations
ERROR - {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry 'ar' for key 'PRIMARY' at /usr/share/koha/lib/C4/Installer.pm line 739
Comment 1 victor 2022-06-13 10:23:40 UTC
Version Koha 22.05
Comment 2 Fridolin Somers 2022-06-13 20:54:37 UTC
Hi,

We have seen this one only once, on a very old database (started at 3.2).

We detect it with :
MariaDB [koha]> SELECT language_subtag,GROUP_CONCAT(script_subtag SEPARATOR ' | '),COUNT(*) AS nb\
    ->     FROM language_script_mapping GROUP BY language_subtag HAVING nb > 1;
+-----------------+---------------------------------------------+----+
| language_subtag | GROUP_CONCAT(script_subtag SEPARATOR ' | ') | nb |
+-----------------+---------------------------------------------+----+
| ar              | Arab | Arab                                 |  2 |
| he              | Hebr | Hebr                                 |  2 |
+-----------------+---------------------------------------------+----+

And fix with :
DELETE FROM language_script_mapping WHERE language_subtag = 'ar' LIMIT 1 ;
DELETE FROM language_script_mapping WHERE language_subtag = 'he' LIMIT 1 ;
Comment 3 victor 2022-06-13 21:49:31 UTC
(In reply to Fridolin Somers from comment #2)
> Hi,
> 
> We have seen this one only once, on a very old database (started at 3.2).
> 
> We detect it with :
> MariaDB [koha]> SELECT language_subtag,GROUP_CONCAT(script_subtag SEPARATOR
> ' | '),COUNT(*) AS nb\
>     ->     FROM language_script_mapping GROUP BY language_subtag HAVING nb >
> 1;
> +-----------------+---------------------------------------------+----+
> | language_subtag | GROUP_CONCAT(script_subtag SEPARATOR ' | ') | nb |
> +-----------------+---------------------------------------------+----+
> | ar              | Arab | Arab                                 |  2 |
> | he              | Hebr | Hebr                                 |  2 |
> +-----------------+---------------------------------------------+----+
> 
> And fix with :
> DELETE FROM language_script_mapping WHERE language_subtag = 'ar' LIMIT 1 ;
> DELETE FROM language_script_mapping WHERE language_subtag = 'he' LIMIT 1 ;

Thank you very much!
The issue was resolved with your guidance.
Comment 4 David Cook 2022-07-06 01:52:08 UTC
Cheers, Fridolin. Just bumped into this one myself, so your fix was very helpful!

I was tempted to close the issue but really this is something that Bug 29605 should've watched out for I suppose...

I'm not sure what the answer is for fixing an old database migration... I suppose we would need to fix /usr/share/koha/intranet/cgi-bin/installer/data/mysql/db_revs/211102003.pl since ordering is critical...
Comment 5 Katrin Fischer 2022-07-31 10:42:22 UTC
Could we fix the old database update and implement the proposed fix as a new one to catch all?
Comment 6 David Cook 2022-08-01 02:08:51 UTC
(In reply to Katrin Fischer from comment #5)
> Could we fix the old database update and implement the proposed fix as a new
> one to catch all?

Makes sense to me. I'm just not sure how we do that as a process. Do we do a patch against master for the database update (for the past), and then stable branches backport it?
Comment 7 Katrin Fischer 2022-08-01 14:32:30 UTC
(In reply to David Cook from comment #6)
> (In reply to Katrin Fischer from comment #5)
> > Could we fix the old database update and implement the proposed fix as a new
> > one to catch all?
> 
> Makes sense to me. I'm just not sure how we do that as a process. Do we do a
> patch against master for the database update (for the past), and then stable
> branches backport it?

I'd say so.