zeitgeist team mailing list archive
-
zeitgeist team
-
Mailing list archive
-
Message #02341
Re: [Bug 602211] Re: Monitoring Create/Move/Copy Files events
I am aware of that issue and am brainstorming to solve it.
for that we will need to have 2 more columns
lets try your example:
event with foo.txt
uri_id | value | new_uri_id | old_uri_id |
---------------------------------------------------------
1 | foo.txt | -1 | -1
event "renaming/moving" foo.txt to bar.txt
uri_id | value | new_uri_id | old_uri_id |
---------------------------------------------------------
1 | foo.txt | 2 | -1
2 | bar.txt | -1 | 1
event "creating" new foo.txt.
uri_id | value | new_uri_id | old_uri_id |
---------------------------------------------------------
1 | foo.txt | -1 | -1
2 | bar.txt | -1 | 1
This implies that foo.txt is new since it has no old uri not does it have a
new one
however bar.txt is linked to foo.txt since the old foo.txt is its origin.
This will allow me to search bar.txt and get foo.txt as a result (which is
not good for feature events) but foo.txt is not linked to bar.txt
We need more time for that issue
On Tue, Nov 9, 2010 at 2:39 PM, Siegfried Gevatter <rainct@xxxxxxxxxx>wrote:
> 2010/11/9 Seif Lotfy <602211@xxxxxxxxxxxxxxxxxx>:
> > OK I think we can just add 1 column that links to the new uri in the uri
> > table so it becomes
>
> Keep in mind that the same URI can be reused for different things,
> though. I may rename foo.txt to bar.txt and create a new foo.txt.
>
> --
> 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 Zeitgeist Framework: Confirmed
> Status in Zeitgeist Datahub: Incomplete
>
> 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/zeitgeist/+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 Zeitgeist Framework: Confirmed
Status in Zeitgeist Datahub: Incomplete
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 :)
References