Bug 160840

Created attachment 24328 [details]
recursive view too perfect?

Andi,

Right. This is a bug.

Arnd, i suspect a problem with method to get recursive album hierarchy from database...

Gilles Caulier

SVN commit 797277 by abaecker:

Only show folders below a given folder in recursive view mode. 
For this the whole path of a folder has to be matched from the beginning.

CCBUGS: 160840
TODO:KDE4PORT



 M  +2 -1      NEWS  
 M  +1 -1      kioslave/digikamalbums.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=797277

Hi Andi,

thanks a lot for the detailed and clear description of the problem!

The problem was in   kioslave/digikamalbums.cpp :

        if (recurseAlbums)
        {
            // Search for albums and sub-albums:
            // For this, get the path with a trailing "/".
            // Otherwise albums on the same level like "Paris", "Paris 2006",
            // would be found in addition to "Paris/*".
            urlWithTrailingSlash = kurl.path(1);

            m_sqlDB.execSql(QString("SELECT DISTINCT id, url FROM Albums WHERE
url='%1' OR url LIKE '\%%2\%';")
                            .arg(escapeString(url)).arg(escapeString(urlWithTrai
lingSlash)), &albumvalues);
        }

So in your particular example, a search for "/one2one"
is performed. The "OR  url LIKE '...'" will also return those files
with "/2007/one2one".

The solution is to omit the first \% in the query.
(see e.g. http://www.techonthenet.com/sql/like.php )

It works fine for me now, but if possible, it would be nice
if you could compile current svn to make sure that it works fine for you.

Gilles, Marcel: I don't know if the code is the same in KDE4, so
please check and backport if necessary.

Best, Arnd

Hi,

just build an archlinux digikam-svn package to test the new version and it seems to work fine now! The package is based on SVN 797277...

This might not be a result of the bugfix but "scanning for new items on startup" isn't working anymore. Manually scanning for new media works, but not when I close digikam and restart it again.

I would be surprised, if that was caused by my fix (hope not! ;-).
But you can easily check by adding the \% into the string
(as shown in #c4).

At least here scanning still works  fine ...
(Your images are on a local disk?)

Best, Arnd

Beta3 worked fine, too. It only scans for new images when I switch the location of the image database. I have two locations for images, private ones (/mnt/data/photos) and a location for my company related stuff (/home/andi/somthing...blabla). When switching between those two databases, the scan is performed, but restarting digikam won't scan for new images anymore. Also when I delete an album, it stays in the folder tree view, I have to scan manually for new images to get rid of the deleted folder.

Ok, I just disabled the splash screen and now the scan dialog is visible again, so I guess it is just hidden by the splash... scanning works fine.

Andi,

Absolutely. If splash is enabled, no scan dialog appears, following this entry :

http://bugs.kde.org/show_bug.cgi?id=142469

Gilles Caulier

Hi Gilles,

well the scan dialog appeared for me in beta3 as well, so I was a little surprised why it was gone when checking out the latest SVN snapshot.

Marcel,

In KDE4, implementation is completely different. We use ImageLister class now.

Back-porting #3 patch from Arnd, is a non-sence, but testing if problem can be reproduce yes...

Here, i cannot see any dysfunction. And you ?

Gilles Caulier

Arnd,

To be clear, digikamalbums kio slave use ImageLister class :

http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/database/imagelister.cpp?revision=792261&view=markup

and especially the method ImageLister::listAlbum() with m_recursive flag :

...
QString query = "SELECT DISTINCT Images.id, Images.name, Images.album, "
                    "       ImageInformation.rating, ImageInformation.creationDate, "
                    "       Images.modificationDate, Images.fileSize, "
                    "       ImageInformation.width, ImageInformation.height "
                    " FROM Images "
                    "       LEFT OUTER JOIN ImageInformation ON Images.id=ImageInformation.imageid "
                    " WHERE ";

if (m_recursive)
{
    DatabaseAccess access;
    query += "Images.album IN (";
    access.db()->addBoundValuePlaceholders(query, albumIds.size());
    query += ");";
    access.backend()->execSql(query, albumIds, &values);
}
...

Gilles

To append to #13:
albumIds is a list with the relevant album ids, which are retrieved, if m_recursive is true, with a call to AlbumDB::getAlbumAndSubalbumsForPath()
(imagelister.cpp line 186).
The AlbumDB code looks like this:
    d->db->execSql( QString("SELECT id FROM Albums WHERE albumRoot=? AND (relativePath=? OR relativePath LIKE ?);"), albumRootId, relativePath, relativePath + "/%", &values);

The finished SQL would look like this:
SELECT id FROM Albums WHERE albumRoot=0 AND (relativePath='/one2one' OR relativePath LIKE '/one2one/%');

Arnd, I think that is already the same code as in your fix.

Gilles, Marcel: thanks for the explanation - yes, this looks completely ok
(The problem was that the leading /% also allowed for sub-albums
to match).

All seems fine now, closing this bug as fixed.