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 <
<email address hidden>> 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