Using digiKam with a LOT of tags

[Gilles Caulier]

Hi Veaceslav,

Look like the Qcompleter is not really the problem. Maik has fixed the
problem already.

https://bugs.kde.org/show_bug.cgi?id=376661#c4

It's to populate the tree-view with items. It take a while.

Giles

2017-02-22 15:45 GMT+01:00 Veaceslav Munteanu <
veaceslav.munteanu90 at gmail.com>:

> I am not sure if this will help, but for QCompleter implementation,
> allows to specify if the model is sorted or not.
>
> If the elements are sorted, and we specify this with
> http://doc.qt.io/qt-4.8/qcompleter.html#modelSorting-prop, we can get
> a huge improvement, because of binary search vs normal search.
>
> On Sun, Feb 19, 2017 at 6:03 PM, Gilles Caulier
> <caulier.gilles at gmail.com> wrote:
> > Well, I know that Maik, have performed some investigations and apply some
> > patches. Just report and comment on bugzilla, he is in CC. We will see...
> >
> > Gilles Caulier
> >
> > 2017-02-19 17:59 GMT+01:00 Alexander Langley
> > <alexander.g.langley at gmail.com>:
> >>
> >> Ah, I see. I apologize for not doing sufficient research before sending
> >> mail to the list. Is it possible to disable autocompletion without
> >> recompiling from source?
> >>
> >> - Alex
> >>
> >> On Feb 19, 2017, 11:51 -0500, Gilles Caulier <caulier.gilles at gmail.com
> >,
> >> wrote:
> >>
> >>
> >> The problem is not the tags amount in fact, and not the database.
> >>
> >> The problem is located in search text widget used to filter tree-view.
> >> When
> >> you start digiKam the widget is populated with tags a album name to
> >> provide
> >> auto completion. The loop inside the Qt widget model is like O(n^2) and
> >> hang-up.
> >>
> >> The possible solution is to disable autocompletion in this areas for the
> >> moment.
> >>
> >> The problem is reported in this file :
> >>
> >> https://bugs.kde.org/show_bug.cgi?id=367853
> >>
> >> .. and also already reported in this room...
> >>
> >> The problem is identified at least. We need a strategy to prevent this
> >> dysfunction.
> >>
> >> Gilles Caulier
> >>
> >>
> >>
> >> 2017-02-19 16:30 GMT+01:00 Alexander Langley
> >> <alexander.g.langley at gmail.com
> >> :
> >>
> >> Hello digiKam Users,
> >>
> >> digiKam Version: 5.4.0 (via Homebrew)
> >> OS: macOS
> >> OS Version: 10.12.3 (Sierra)
> >> PC Specs: Intel core i5, 4GB RAM
> >>
> >> I'm currently working on a project that requires I use a VERY LARGE
> number
> >> of
> >> tags. And by "VERY LARGE", I mean on the order of 220,000. After reading
> >> the
> >> digiKam database spec, I wrote a quick Python script to read my tag set
> in
> >> from
> >> a source JSON document and add it to the digiKam database using the
> >> sqlite3
> >> library.
> >>
> >> This did not make digiKam happy. When I attempted to launch it after
> >> adding the
> >> tags, it hung indefinitely at the loading screen step labeled "Reading
> the
> >> Database..." I verified that I hadn't mangled the database format, then
> >> tried
> >> again, only to be met with the same hang. By reducing the number of tags
> >> 85%
> >> (33,000), I was able to convince digiKam to start again, but it took 10
> >> minutes
> >> for it to open...
> >>
> >> Is this a supported use case? Is there a box I can check somewhere to
> >> tweak
> >> digiKam's database loading system to handle absurd numbers of tags? If
> >> not,
> >> would a code contribution to try to speed up tag loading be welcome?
> >>
> >> - Alex
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170222/91b7ff1d/attachment.html>