zeitgeist team mailing list archive

[Seif Lotfy <602211@xxxxxxxxxxxxxxxxxx>]

I think it easy for clients to determine subjects that have been deleted
by calling exists on the uri. Of course we can detect delete events from
nautilus too and thusly change the "current_uri" for it.

But again to the solution for solving "moved" files. The solution proposed by Mikkel (modified by me) could make things messy.
Once a file is moved we have to query on both subject_current_uri and subject_uri. right? 

So lets say I have a file that has been moved from /home/seif/foo to /home/seif/bar. This means I query for all events where subject_uri = /home/seif/foo so I get all results until the point it was moved, right? And if I ask for /home/seif/bar I get all events with
subject_uri = /home/seif/foo as well as all subject_uri = /home/seif/bar ... ?

-- 
Monitoring Create/Move/Copy Files events
https://bugs.launchpad.net/bugs/602211
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.

Status in Unity: Triaged
Status in Unity Files Place: Triaged
Status in Zeitgeist Framework: Confirmed
Status in Zeitgeist Datahub: Confirmed

Bug description:
An issue we are facing at the moment is that ppl lose track of there files in a timeline if the file was moved around or renamed. I would propose using taskview or patch nautilus to actually grab those events and either:
1) Modify the uris in the uris table
2) Create a new table with    | new_id | old_uri_id | event | to map uris to their actual ids and the event that allowed the change, this would allow us to track a history of renaming or moving a file. It will look a bit like the following:

9 | 9 | 48124  # CREATE EVENT
12 | 9 | 48126 # MOVE EVENT

In other words the last row means uri 12 was moved from uri 9 with event 48126

UPDATE:

3) Create a changable_uri table that is a map of the uri table. it gets updated upon moved and rename.
We then add new resulttype that allow you to ask for either pureSubject or adaptedSubject. depending on which one is chosen we then use the according table in the join of the find_events_query :)