Bug 373003

A new uniqueHash algorithm was implemented a few years ago. See https://bugs.kde.org/show_bug.cgi?id=210353. The new algorithm in uniqueHashV2 was only made available for newly created databases. An already existing database was (and is till today) still using the old uniqueHash algorithm. My 10 years old digikam db still uses the old uniqueHash algo. The old algo worked fine till digikam 4.14. During the porting to DK 5, a bug was introduced for the old algo:

In dimgloaded.cpp, the KDE4 command for the old v1 uniqueHash algo
  
   KMD5 md5;
   ...
   hash = md5.hexDigest();

was replaced in the KDE5 porting with ( still uniqueHash v1)

   QCryptographicHash md5(QCryptographicHash::Md5);
   ...
   hash = md5.result();

which is wrong. Instead, it should have been replaced by

   QCryptographicHash md5(QCryptographicHash::Md5);
   ...
   hash = md5.result().toHex();

See the migration document https://api.kde.org/frameworks/kdelibs4support/html/classKMD5.html#a49b31c3e5eb180fa8be8c8f576266221

As a consequence, a database created before 2010 calculates different uniqueHash values in DK5 compared to DK4. Furthermore, UTF8 cannot be used since some of the now calculated uniqueHash values are not valid UTF8 characters, the SQL server erorrs with

  "REPLACE INTO Images  ( album, name, status, category, modificationDate,
  fileSize, uniqueHash )  VALUES (?,?,?,?,?,?,?);"
  Error messages: "QMYSQL3: Unable to execute statement" "Incorrect string
  value: '\\xF1\\x9E\\xA6\\x87' for column 'uniqueHash' at row 1" 1366 2
  Bound values:  (QVariant(int, 118053), QVariant(QString, "P4240656.JPG"),
  QVariant(int, 1), QVariant(int, 1), QVariant(QString,
  "2016-10-30T19:16:42"), QVariant(qlonglong, 6951936), QVariant(QString,
  "m�7�\U0005E987"))

There is uniqueHashVersion in the System table, but the value "2" in DK4 and DK5 return different hash values.

The fix would be easy, just add the missing ".toHex()". However, all images added in DK5 already contain the invalid hash values. They need legacy treatment.

The most clean solution is to get rid of hashValue version 1 and recalculate all hash values in the next DK release

As as sidenote: hashValueV2 is not affected by this bug. This means a db created after 2010 is not affected