Bug 372540

Summary: fileSize field in Images table limited to 4GB
Product: [Applications] digikam Reporter: Brian J Hoskins <brian>
Component: Database-SchemaAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: brian, caulier.gilles, kusi
Priority: NOR    
Version: 5.3.0   
Target Milestone: ---   
Platform: Kubuntu   
OS: Linux   
Latest Commit: Version Fixed In: 5.4.0

Description Brian J Hoskins 2016-11-16 15:05:54 UTC
While attempting to migrate a 4.x SQLite database to mySQL I encountered the following error:

"Error while converting the database.
Details: Out of range value for column 'fileSize' at row 1"

I have some large video files in the collection, so I checked the variable type for the fileSize field in the Images table.  It is set to int, which means that the largest number which can be stored is 2^32 (4GB).

To test if this was the cause, I ran the migration tool again and then after the schema was created I manually changed the field type to bigint(64-bit) while the migration tool was running.  This enabled digikam to process the larger files.

To test my thinking further, I created a fresh SQLite database and added one 5.2GB mp4 file to it.  I then tried to migrate that database to mySQL and encountered the same error.

*SUGGESTIONS*

1. Change fileSize type in Images table to bigint.
2. Enable the database migration error dialogue to print the name of the file it was trying to process when the error was encountered.  This will make other issues easier to identify.
Comment 1 Kusi 2016-11-26 00:06:16 UTC
I can confirm that 

ALTER TABLE Images MODIFY COLUMN fileSize BIGINT NULL;

does the trick. Nowadays, it's common to have movies larger than 2G
Comment 2 Maik Qualmann 2016-11-27 19:59:24 UTC
Git commit 80017e16f30e9ea4e97fe1a7c78dbaab7e66bd94 by Maik Qualmann.
Committed on 27/11/2016 at 19:58.
Pushed by mqualmann into branch 'master'.

change fileSize field to BIGINT in MySQL DB schema v8
FIXED-IN: 5.4.0

M  +2    -1    NEWS
M  +4    -2    data/database/dbconfig.xml.cmake.in

https://commits.kde.org/digikam/80017e16f30e9ea4e97fe1a7c78dbaab7e66bd94
Comment 3 Kusi 2016-11-27 23:19:54 UTC
what about those who already have updated to schema v8? They're not getting this fix, do they?