https://bugs.kde.org/show_bug.cgi?id=528078
Bug ID: 528078
Summary: DigiKam 9.1.0 truncates IPTC Sub-location (location)
to exactly 32 bytes in MySQL database, despite full
data in file and longtext DB column.
Classification: Applications
Product: digikam
Version First 9.1.0
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: major
Priority: NOR
Component: Metadata-Iptc
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Description:
When writing metadata to the digiKam MySQL database, the location (IPTC
Sub-location) property is incorrectly truncated to exactly 32 bytes. This
happens even though the database column is longtext (which has no such limit),
the database uses utf8mb3/utf8mb4 collation, and the actual image file contains
the full, untruncated metadata.
This appears to be a bug where digiKam incorrectly applies the legacy IPTC IIM
32-byte limit to the modern database storage layer during the write operation.
Steps to Reproduce:
1. Configure digiKam to use a remote MySQL/MariaDB database with utf8mb4
character set.
2. Enable "Use ExifTool for all metadata writing operations" in Settings ->
Metadata -> Behavior.
3. Create a metadata template with a Cyrillic Sub-location string longer than
16 characters (e.g., "Александрийский парк", which is 20 characters / 40 bytes
in UTF-8).
4. Apply this template to an image.
5. Query the imageproperties table in the digiKam database for the location
property of that image.
6. Compare the value shown in the main digiKam window with the value shown in
digiKam's ShowFoto (which reads directly from the file).
Observed Result:
The value in the imageproperties table is truncated to exactly 32 bytes. For
the string "Александрийский парк" (40 bytes), the database stores
"Александрийский ." (17 characters, 32 bytes). The main digiKam window displays
this truncated version.
Expected Result:
The full string ("Александрийский парк", 40 bytes) should be stored in the
longtext column without truncation, matching the data correctly written to the
image file.
Technical Evidence:
1. ShowFoto reads the file correctly: ShowFoto displays the full, untruncated
Sub-location, proving the file itself is not corrupted.
2. Database query proves truncation on write:
mysql> select property, length(value), char_length(value), value
from imageproperties
where imageid in (select id from images where name like 'DSCF3501%')
and property = 'location';
+----------+---------------+--------------------+----------------------+
| property | length(value) | char_length(value) | value |
+----------+---------------+--------------------+----------------------+
| location | 32 | 17 | Александрийский . |
+----------+---------------+--------------------+----------------------+
3. Table schema allows full length:
CREATE TABLE `imageproperties` (
`imageid` bigint NOT NULL,
`property` longtext CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT
NULL,
`value` longtext CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
Additional Information:
The issue is strictly related to the database write operation. External tools
(ExifTool) and digiKam's own ShowFoto confirm the source file metadata is
intact. This truncation breaks searching and cataloging by location within the
main digiKam interface for non-Latin scripts.
--
You are receiving this mail because:
You are watching all bug changes.
