Nepomuk in 4.13 and beyond

Marco Martin notmart at gmail.com
Fri Dec 13 11:42:39 GMT 2013


On Thursday 12 December 2013, Vishesh Handa wrote:
> On Thursday 12 Dec 2013 19:40:11 Ivan Čukić wrote:
> > > If we all decide to store stuff in sqlite, then it doesn't matter if
> > > they are separate database files or the same one.
> > 
> > I might be missing a few things here, but asking questions is the road to
> > enlightenment :)
> > 
> > - There is no way to query across different stores, which was the main
> > appeal of nepomuk? (I concluded this from the last mail)
> 
> There isn't one. Not right now. I'm open to ideas on how to do something
> like if it is required. I'm slightly skeptical if it actually is required.

- query attachments saved on disk sent by $person?
- tags or activities  associations
- 

> > - When querying, how do I get the properties of the results?
> 
> You don't. You just get the identifier and some text. You can do a
> subsequent fetch job to get additional data.

ouch, if i have to display a lot of results that looks very heavy, and a loot 
of jobs, just a bit worried about that


> > From my POV, it would be much nicer if you forced a single db (as an
> > actual store, not as a cache like nepomuk is for akonadi) on the people,
> > with the option to have a few things runtime defined. It would ease the
> > development and would allow more fun queries which would be optimized
> > unlike the manual client-side joining of different query results.
> 
> But what if one doesn't use SQL for storing data? IMO Xapian is much better
> suited that sqlite's FTS support (or mysql).
> 

Xapian is just for files indexing, right? (and no, file indexing with sqlite 
would blow up in a nuclear explosion;)

what i would see is a central sqlite db with just relations between stuff.
* tag/anything (being file, email, whatever)
* activity/anything
* anything/anything (so explicit relation between contanct and file for 
instance)

that sqlite db makes sense being sqlite since the amount of data in it would 
probably stay pretty limited (mostly relations hand made, anyways around 
hundreds of items max vs the hundred thousands of the file index for instance)

then the actual file metadata, email metadata etc can be stored wherever

is also important having more flexible queries, like sql directly exposed (in 
plasma active i *need* to have group by, that's the reason we used directly 
sparql in some queries)

Cheers,
Marco Martin




More information about the kde-core-devel mailing list