TBH I am not fond of the idea of having the file monitor inside Zeitgeist. Zeitgeist is about events first. Also this means we will need to reside on inotify and this is a BIG NO from me again. Unless we have fanotify I dont even think we should look at the solution being inside Zeitgeist TBH. I however do like the idea of extending the event table as a fallback solution for now, although it really does break the idea of an event is immutable. I am trying to convince myself that this is not an issue though.
So I want to propose a new solution that builds on top of Mikkel's idea. * change the event table to include current_subject_uri * add a logic that handles MOVE/COPY/RENAME events * listen to MOVE/COPY/RENAME events from outside sources such as nautilus (by patching, ssickert has a patch) What do you think? On Thu, Nov 11, 2010 at 9:27 AM, Mikkel Kamstrup Erlandsen < mikkel.kamst...@gmail.com> wrote: > All of these clever remapping schemes scare me a bit to be honest. > They all seem to imply a non-negligible impact on our query time, and > a considerable amount of logic. > > A simpler and more performant scheme, which requires an API break (!), > is to simply add an extra field on our Subject structure > "current_uri". In the DB we represent this as an extra column on the > 'event' table which holds the URI id of the current location of the > subject. > > Doing it like this would require that the file monitor lives inside > Zeitgeist - and not as an extension, but as a core component, since it > requires a special db structure. The file monitor would then directly > modify the 'current_uri' column of the 'event' table on file events. > This breaks our "events are immutable" invariant - which i'm otherwise > very fond of... So there are many drawbacks to this approach. > > Despite all the drawbacks something inside me tells me that something > like this is the right solution. > > I very much dislike adding advanced stuff like a file monitor as a > core component, but we could make up for this, by having it be like a > stub, that didn't do anything by default, but would have to be > instrumented by an extension or something... So it requires air fair > deal of thought architecture wise... > > -- > Monitoring Create/Move/Copy Files events > https://bugs.launchpad.net/bugs/602211 > You received this bug notification because you are a direct subscriber > of the bug. > > 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 :) > > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/unity/+bug/602211/+subscribe > -- This is me doing some advertisement for my blog http://seilo.geekyogre.com -- 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 :) _______________________________________________ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
