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'; http://www.sqlite.org/lang_attach.html 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 - http://xapian.org/docs/postingsource.html > 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; q.setType("File"); q.addRelation(TagRelation(Tag("Spiderman")); q.addRelation(ActivityRelation(someActivity)); 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