Nepomuk in 4.13 and beyond

[Ivan Čukić]

> 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.

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.

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.

Cheerio,
Ivan


-- 
Acting is merely the art of keeping a large group of people from coughing.
  -- Sir Ralph Richardson