> 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
