Bug 160840 - Wrong filtering on Album-Subtree-View
Summary: Wrong filtering on Album-Subtree-View
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-Filters (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-14 21:40 UTC by Andi Clemens
Modified: 2012-08-09 07:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 0.9.4


Attachments
recursive view too perfect? (278.72 KB, image/png)
2008-04-14 21:40 UTC, Andi Clemens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andi Clemens 2008-04-14 21:40:10 UTC
Version:           0.9.4-beta3 (using 3.5.9, Arch Linux)
Compiler:          Target: i686-pc-linux-gnu
OS:                Linux (i686) release 2.6.24-ARCH

When I have "Include Album-Sub-Tree" checked, I can see folders recursively.
But it seems to work too perfect (but maybe it is a feature I am not aware of).

I have a folder structure like this:

2001
    |- ABC
    |- one2one
2003
    |- ABC
    |- one2one
2007
    |- ABC
    |- DEF
    |- one2one
one2one
    |- Folder A
    |- Folder B
    |- Folder C

When I click on the one2one root folder (/one2one), I can see all subfolders in
it (Folder A, Folder B, Folder C), but also the other ones from 2001, 2003 and
2007 with the name 'one2one'. I'll attach a screenshot of this "problem".

I don't know if this is normal, but somehow I think this is not right :-) Or is
it?
Comment 1 Andi Clemens 2008-04-14 21:40:49 UTC
Created attachment 24328 [details]
recursive view too perfect?
Comment 2 caulier.gilles 2008-04-14 23:06:06 UTC
Andi,

Right. This is a bug.

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

Gilles Caulier
Comment 3 Arnd Baecker 2008-04-15 12:04:33 UTC
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
Comment 4 Arnd Baecker 2008-04-15 12:07:02 UTC
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
Comment 5 Andi Clemens 2008-04-15 13:37:53 UTC
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...
Comment 6 Andi Clemens 2008-04-15 13:54:29 UTC
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.
Comment 7 Arnd Baecker 2008-04-15 14:50:08 UTC
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
Comment 8 Andi Clemens 2008-04-15 15:23:51 UTC
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.
Comment 9 Andi Clemens 2008-04-16 01:13:14 UTC
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.
Comment 10 caulier.gilles 2008-04-16 06:20:50 UTC
Andi,

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

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

Gilles Caulier
Comment 11 Andi Clemens 2008-04-16 12:05:59 UTC
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.
Comment 12 caulier.gilles 2008-04-17 12:23:05 UTC
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
Comment 13 caulier.gilles 2008-04-17 12:26:50 UTC
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
Comment 14 Marcel Wiesweg 2008-04-17 15:12:53 UTC
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.
Comment 15 Arnd Baecker 2008-04-17 15:46:54 UTC
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.