[Kde-pim] Akonadi datamodel questions

[Christian Schaarschmidt]

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-apidoc
>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

- no Flags
  flags are meta data

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

>
> > 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. 

> 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?

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

- 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 ? 

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

Regards
Christian
_______________________________________________
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/