[Digikam-devel] [digikam] [Bug 323062] digikam (core): Schema update to V 7 failed!

TSa thomas at sandlass.de
Sun Aug 18 15:08:51 BST 2013


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

TSa <thomas at sandlass.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas at sandlass.de

--- Comment #13 from TSa <thomas at sandlass.de> ---
HaloO,

I am not sure if I should hijack this bug or open a new one. Sorry for any
inconvenience.

Recently i tried to upgrade from digikam 0.93 on kubuntu 8.04 to digikam 3.1 on
kubuntu 13.04.
At startup digikam tried to convert the database version. While this happened I
saw a progressbar
and the message "throwing away V3 tables" then the error that the upgrade from
V6 to V7 failed
has occurred. I confirm this with OK and the message box disappears. Thereafter
all my albums, photos and tags are visible. However when I restart digikam I
get just the V6 to V7 error and no photos and tags are loaded.

I can reproduce the initial behaviour by deleting the digikam4.db file and
restarting with the original digikam3.db file.

I have upgraded digikam to version 3.2 following a tutorial. This gave me a
core dump on the update dialog. For investigating this I have tried to build
the newest version from GIT but the configure failed on my kubuntu 13.04
environment for not being new enough. So I have built
version 3.2 for debugging and found the reason for the core dump:

void CollectionScanner::scanFileNormal(const QFileInfo& fi, const ItemScanInfo&
scanInfo)
{
    bool hasAnyHint = d->hints && d->hints->hasAnyNormalHint(scanInfo.id);

    // if the date is null, this signals a full rescan
    if (scanInfo.modificationDate.isNull() || 
        (hasAnyHint && d->hints->hasRescanHint(scanInfo.id)) )
    {
      if (d->hints) // TSa added: could be null
        {
            QWriteLocker locker(&d->hints->lock);
            d->hints->rescanItemHints.remove(scanInfo.id);
        }
        rescanFile(fi, scanInfo);
        return;
    }

I have fixed it by checking d->hints for null. Then 3.2 behaves exactly as 3.1:
I see all my tags
when starting from the digikam3.db file but not from the digikam4.db file.

Unfortunately I am not a database developer but I am willing to debug this as
needed. What I could find out easily is the offending DBAction. For printing it
in gdb I´ve copied the QString into a temporary const char *sm that can be
printed. Here is the debug  result in
DatabaseCoreBackend::QueryState DatabaseCoreBackend::execDBAction(
     const DatabaseAction& action, const QMap<QString, 
         QVariant>& bindingMap, QList<QVariant>* const values, 
    QVariant* const lastInsertId)

(gdb) p sm
$1 = 0x7fffcc00c188 " CREATE TABLE VideoMetadata\n", ' ' <repeats 28 times>,
"(imageid INTEGER PRIMARY KEY,\n", ' ' <repeats 28 times>, "aspectRatio
TEXT,\n", ' ' <repeats 28 times>, "audioBitRate TEXT,\n", ' ' <repeats 21
times>...
(gdb) n
660                 result = execDirectSql(actionElement.statement);
(gdb) 
663             if (result != DatabaseCoreBackend::NoErrors)
(gdb) p result
$2 = {value = Digikam::DatabaseCoreBackend::SQLError}

OK, this is where I´m standing right now. What should I do next to investigate
the problem?

Regards TSa.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Digikam-devel mailing list