Re: [Tracker] Tracker Internal Documentaion

[Philip Van Hoof <philip codeminded be>]

On Thu, 2013-04-11 at 18:12 +0530, Vishesh Handa wrote:



> If it's possible could you please elaborate as to how this is
> implemented in the database?

It's implemented in the SQLite tables as an extra column.


> Oh. So, suppose a music file existed with a performer "Coldpay" and
> modified the id3 tags to now say "Coldplay". The file would get
> reindexed and it would now have both performers? The old and the new
> one?

> The performer is generally stored with a 'nmm:performer' property and
> does not have a max cardinality of 1.

No, multivalue properties are first clearned and then rewritten (by
miner-fs). When another client adds a value to a multivalue property
then the graph of all is set to the clients', so miner-fs wont overwrite
it anymore.

An example:

1) file.mp3 a nmm:MusicPiece has nmm:performer 'somebody' as extracted
by tracker-extract/miner-fs and written in tracker-store:

GRAPH <miner-fs> {
<urn> a nmm:MusicPiece, nfo:FileDataObject;
   nie:url 'file://.../file.mp3';
   nie:title 'test';
   nmm:performer 'somebody' .
}

2) client updates nmm:performer:

GRAPH <client> {
<urn> nmm:performer 'somebody else' .
}

3) Result:

GRAPH <miner-fs> {
<urn> a nmm:MusicPiece, nfo:FileDataObject;
   nie:title 'test';
   nie:url 'file://.../file.mp3' ;
   nfo:lastModifiedSomething '...' .
}

GRAPH <client> {
<urn> nmm:performer 'somebody else' .
}

4) miner-fs sees an update on file.mp3, update is on performer and
title:

GRAPH <miner-fs> {
  <urn> nie:title 'new title';
        nfo:lastModifiedSomething '...' .
}

Because miner-fs won't change statements that aren't in its own graph
and because we support only one graph per statement (meaning that client
has overwritten it for nmm:performer).

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be