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
_______________________________________________
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list
