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