https://bugs.kde.org/show_bug.cgi?id=388824

Nico Kruber <nico.kru...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nico.kru...@gmail.com
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---
     Ever confirmed|0                           |1

--- Comment #4 from Nico Kruber <nico.kru...@gmail.com> ---
actually, this is not really enough without adding something like

<statement mode="plain">SET FOREIGN_KEY_CHECKS=0;</statement>

before trying to migrate the quirky tables. My problem was with the Tags table
because of this in the (new) dbconfig.xml:

                <statement mode="plain">RENAME TABLE Tags TO
Tags_old;</statement>
                <statement mode="plain">CREATE TABLE Tags LIKE
Tags_old;</statement>
                <statement mode="plain">ALTER TABLE Tags
                                        ADD CONSTRAINT Tags_Images FOREIGN KEY
(icon) REFERENCES Images (id) ON DELETE SET NULL ON UPDATE CASCADE,
                                        ADD UNIQUE(pid, name(100)),
                                        ENGINE InnoDB;</statement>
                <statement mode="plain">REPLACE INTO Tags SELECT * FROM
Tags_old;</statement>
                <statement mode="plain">SET @OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='NO_AUTO_VALUE_ON_ZERO';</statement>
                <statement mode="plain">REPLACE INTO Tags (id, pid, name, icon,
iconkde, lft, rgt) VALUES (0, -1, '_Digikam_root_tag_', NULL, NULL,
                                        (SELECT MIN(tl.lft) FROM Tags AS tl),
                                        (SELECT MAX(tr.rgt) FROM Tags AS
tr));</statement>
                <statement mode="plain">SET SQL_MODE=@OLD_SQL_MODE;</statement>
                <statement mode="plain">UPDATE Tags SET icon = NULL WHERE icon
= 0;</statement>

Only the last statement fixes the invalid references to an image with ID 0 but
the foreign key constraint was added before that already and this is why the
REPLACE INTO failed.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to