On Wed, Sep 14, 2011 at 8:27 PM, Sam Thursfield <[email protected]> wrote:
> On Wed, Sep 14, 2011 at 8:35 AM, Martyn Russell <[email protected]> wrote:
>> On 14/09/11 01:35, Sam Thursfield wrote:
>>>
>>> I did like the idea of the URL with a fragment, but now I realise how
>>> much extra data the FS miner attaches when it adds nie:FileDataObject
>>> information - it seems wrong for the tracks of a larger file to also
>>> have type FileDataObject (necessary to set nie:url) but not have any
>>> of the useful file-specific metadata that the FS miner would attach
>>> (because we create the tracks as part of the preupdate).
>>>
>>> It now seems more "correct" to me to make the tracks have no nie:url,
>>> but relate them to the container file with nie:isStoredAs and add a
>>> nmm:containerOffset propery which gives the time offset in the
>>> container. Is this logical?
>>
>> I would be careful when referring to file names too. Currently, renaming or
>> moving files on the disk only requires 1 update in the database and not
>> re-extraction of data. If we start storing path / filename information in
>> other places, it means this can be out of step with rename/move operations.
>
...
> There's one outstanding issue which I'm open to ideas on - how to
> delete the track resources when the file is re-crawled. The obvious
> solution isn't supported by the query parser (unbound predicate):
>
> DELETE { ?track p ?o } WHERE { ?track nie:isStoredAs ?file. ?file
> nie:url "file:///test.flac" . ?track ?p ?o } "
For mailing list archive readers, the correct way to do this in Tracker is:
DELETE { ?track a rdfs:Resource} WHERE { ?track a nmm:MusicPiece ;
nie:isStoredAs ?file . ?file nie:url "file:///test.flac" }"
I've pushed a new version of the branch to cuesheets-0.12 and I
consider it ready for review. There are tweaks that can be done etc.
but everything is working.
Sam
_______________________________________________
tracker-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/tracker-list
