[Kde-pim] Akonadi datamodel questions

[Volker Krause]

On Wednesday 23 May 2007 21:05:33 Christian Schaarschmidt wrote:
> Am Montag, 21. Mai 2007 18:00 schrieb Volker Krause:
> > On Friday 18 May 2007 19:38:36 Christian Schaarschmidt wrote:
> > > I have attached a modified model to show an alternative to the current
> > > model.
> >
> > I've updated the API docs to actually show the database model we really
> > use currently, auto-generated from the XML definition:
> > http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdepim-apid
> >oc s/akonadi/server/html/akonadi_server_database.html
> >
> > The main difference to your attached file seems to be the use of SQL
> > triggers to keep the modification/access time fields up-to-date, right?
> > Since this would considereably reduce the risk of having code paths
> > missing these updates, it looks like a good idea to me.
>
> besides the triggers both models are quite similar, but there are some
> differences I'd like to point out. I have made some assumptions and based
> on them I suggest these changes. Please let me know it this  makes sens:
>
> - no CachePolicy in Resource
>  one resource can have various locations with mixed cache policies.   I
> don't see why we need additional cache policy in resource. in best case it
> adds redundancy, worst case inconsistent data

The idea for this is: The resource has a default cache policy which is used 
for every of its collections unless it specifies it's own cache policy. This 
IMHO makes sense, but other models might be possible as well, such as 
inheriting the cache policy from the parent collection unless it's 
overwritten.

> - no Flags
>   flags are meta data

Flags means something like read/unread here, this is a very important metadata 
for mail. If however nepumuk/strigi provides this fast enough, removing it is 
of course fine.

> - no relation ship PimItem : MimeType
>   mime type is meta data

see above, the mimetype is essential to create the right Akonadi::Item payload 
on the client side.

> > > BTW, would it be possible to use factory pattern for the storage? It
> > > could help if we decide to replace the db backend in the future or if
> > > someone wants to have his/her preferred db instead of mysql.
> >
> > well, there are basically two kinds of abstractions we could have there:
> > on a SQL database level or on an completely storage-neutral level. We
> > more or less have the first thanks to QSQL with some conditional code for
> > generating the tables, but most of the code deals directly with objects
> > representing records in the database. We intentionally didn't introduce
> > any higher level of abstraction to reduce the work. Is there any non-sql
> > backend that would be interesting to support?
>
> at the moment I don't have an example, just a measure of precaution ...  I
> tend to delegate funktionality to the DB. The more you delegate the harder
> it gets to switch the DB later.

Well, the more we delegate to the DB, the less we have to do ourselves ;-)

> > BTW: with most work currently going into libakonadi and the resources,
> > some help with the server is really appreciated :)
>
> just a few more questions ;-)
>
> - MimeType : Location relationShip
>   does it indicate currently stored or possible to store mime types?

the latter

> - MimeType : PimItemPart relationship
>   I guess that is needed for e.g. attached jpeg

yes, although PimItemPart is not really implemented yet, see below.

> - do we need to coordinate our meta data with Nepomuk project. something
> like naming conventions, interfaces needed by nepomuk, what is stored in
> Nepomuk DB what in akonadi server? is it possible to share the metadata
> store ?

Note that the ItemMetaData table has been dropped already. Meta data should be 
stored in nepomuk/strigi unless it's type-independent and absolutely 
necessary for eg. performance reasons to have them in Akonadi.

> - do you have a particular task in mind, I could start with? I'd like to
> avoid conflicts in svn during commit ;-)

Hm, some ideas are:
- fully implement cache policies: we currently only have a very simple 
proof-of-concept implementation, so there are a lot of possibilities: client 
interface for manageing cache policies, add support for space limits, finish 
support for time limits (I think it's still too aggressive ;-) ), GUI 
elements for selecting/editing policies, ...
- somewhat related: generic interval syncing per resource/collection
- get the strigi/nepomuk feeders working again, they are quite old already and 
seem to need an update to the latest interfaces
- strigi recently got support for XESAM which is a freedesktop search spec 
including live searches. This will finally allow to implement persistent 
searches in Akonadi. Probably the most interesting task of these :)

Other stuff that is needed on the server are item part support and conflict 
detection, but these are covered by Robert's master thesis already.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070524/f06234fe/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/