Nepomuk in 4.13 and beyond

Vishesh Handa me at
Fri Dec 13 11:24:13 GMT 2013

On Thursday 12 Dec 2013 23:33:50 Ivan Čukić wrote:
> > for the Plasma Active shell as it currently is, single-store querying
> > might
> > be workable as we tend to keep most of the different resources separated
> > in
> > the UI (though that’s one thing i want to change in future releases, so
> > you
> > can group a set of bookmarks with a given file, e.g.)
> Piggy-backing on Aaron's sub-thread.
> Here's a simpler, yet "funnier" example: I want all files tagged as
> 'Dolphin' from 'KDE development' activity.
> Tags for files are located in one store. Things linked to an activity are in
> another store.
> If I got it right, I'd have to:
> 1 - get a list of things tagged with 'Dolphin'
> 2 - get a list of things linked to 'KDE development' activity
> Intersect them.

If both are sqlite, then it's one query -

select fid from tagRelation, activityRelation where aid = 'activityId' and tid 
= 'TagIdentifier';

This will also work if tags are in xapian and activities in something else 
since xapian provides ways to filter the query when it is running -

> So, we need to do this manually, in-memory, loading potentially hundreds of
> results in order to return a dozen? While the database would do that in an
> optimized way?
> I do get the problem of some clients desiring sql, and some not (xapian or
> whatever else). We would need a way to bridge those anyhow, so why not
> bridge them in a common place (baloo) instead of relying on each client to
> implement it by themselves.

I'm glad we're on the same page. If you take a look at baloo/src/core/query.h 
there is an addRelation function which would let you do stuff like -

Query q;

it = q.exec();

This isn't currently implemented, but that was the general idea.

> Returning on one-db-to-rule-them-all-but-not-exactly :)
> Baloo could provide the client a choice of the backend database. Not in the
> sense of mysql vs sqlite vs postgresql, but rather of a db type - choose
> SQL, choose whatever-designation-xapian-has, (ignored: JSON, KeyVals, RDF
> :) etc.)
> This way, more complex queries that are limited to stores based on a
> specific db type would be super-fast, while others would be slower, but
> still faster than manual implementations.

I agree.

Vishesh Handa

More information about the kde-core-devel mailing list