[Gnome-zeitgeist] [Merge] lp:~cando/gnome-activity-journal/audio_preview into lp:gnome-activity-journal
The proposal to merge lp:~cando/gnome-activity-journal/audio_preview into lp:gnome-activity-journal has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~cando/gnome-activity-journal/audio_preview/+merge/40342 Your team GNOME Zeitgeist Team is requested to review the proposed merge of lp:~cando/gnome-activity-journal/audio_preview into lp:gnome-activity-journal. ___ Mailing list: https://launchpad.net/~gnome-zeitgeist Post to : gnome-zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~gnome-zeitgeist More help : https://help.launchpad.net/ListHelp
[Gnome-zeitgeist] [Merge] lp:~cando/gnome-activity-journal/drag_and_drop into lp:gnome-activity-journal
The proposal to merge lp:~cando/gnome-activity-journal/drag_and_drop into lp:gnome-activity-journal has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~cando/gnome-activity-journal/drag_and_drop/+merge/40277 Your team GNOME Zeitgeist Team is requested to review the proposed merge of lp:~cando/gnome-activity-journal/drag_and_drop into lp:gnome-activity-journal. ___ Mailing list: https://launchpad.net/~gnome-zeitgeist Post to : gnome-zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~gnome-zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 672965] [NEW] find_event() queries with timerange other than TimeRange.always() are slow
Public bug reported: When running the attached script you can see that when giving a timerange which does not start at 0 and end at maxint the queries get 400% slower. python sample_timerange_query.py DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([]) PLAN: [0, 0, u'TABLE event WITH INDEX event_actor ORDER BY'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.080176s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.080375s DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view WHERE (timestamp = ? AND timestamp = ?) GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([u'1', u'5']) PLAN: [0, 0, u'TABLE event WITH INDEX event_timestamp'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.260648s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.260838s The reason is simply that the second query uses the 'wrong' index. ** Affects: zeitgeist Importance: Undecided Status: New -- find_event() queries with timerange other than TimeRange.always() are slow https://bugs.launchpad.net/bugs/672965 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: When running the attached script you can see that when giving a timerange which does not start at 0 and end at maxint the queries get 400% slower. python sample_timerange_query.py DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([]) PLAN: [0, 0, u'TABLE event WITH INDEX event_actor ORDER BY'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.080176s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.080375s DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view WHERE (timestamp = ? AND timestamp = ?) GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([u'1', u'5']) PLAN: [0, 0, u'TABLE event WITH INDEX event_timestamp'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.260648s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.260838s The reason is simply that the second query uses the 'wrong' index. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 632363] Re: Slow queries: SQL indexes not used
I've just filed bug 672965 for one class of slow queries -- Slow queries: SQL indexes not used https://bugs.launchpad.net/bugs/632363 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 Bug description: THE PROBLEM: I am seeing query times around 200ms (and 150ms with my latest performance tweak in trunk), which surprised me as quite slow since my queries where quite simple. I had expected times around 1-2ms. Reading up on the sqlite documentation I see that the queries we generate are pretty far from optimized in an sqlite world [1]. The case is that when ever you use an OR sqlite will no longer use an index. Thus this query is NOT using the indexes: SELECT * FROM event WHERE interpretation=1 OR interpretation=2 But if we rewrite it using IN instead the indexes will be used: SELECT * FROM event WHERE interpretation IN (1, 2) This also explains the case where Michal where seeing tremendously slow query times when searching for a big range of mimetypes. Looking in _zeitgeist.engine.sql.WhereClause.add_text_condition() I am also pretty sure we are not using the indexes for prefix queries (eg file://home/*). THE SOLUTION I *definitely* don't think we should panic and feverishly start rewriting our query compilation. Here's what I propose: 1) Implement an envvar ZEITGEIST_DEBUG_QUERY_PLANS which will spit out all our SQL calls and the query plans for each of our calls. The query plan will tell us how the db is queried and which indexes are used if any. The query plan is obtained by prefixing the SQL statement with EXPLAIN QUERY PLAN. 2) Collect some useful intelligence with this new tool, and generally learn more about how we can optimize sqlite queries. A big question here is how the event_view VIEW impacts the query plan. 3) Write a new template - SQL compilation engine that generates SQL optimized for sqlite. We can actually be quite clever about grouping our OR statements into IN clauses - but it will be tricky to get right. NOTE: That this doesn't imply any change in the public API or event template system. That would be the wrong solution imho. Our current API is nice and simple by my standards. Let's keep it that way. [1]: See fx the section Using Indexes To Speed Searching in http://www.sqlite.org/vdbe.html ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 672965] Re: find_event() queries with timerange other than TimeRange.always() are slow
** Description changed: When running the attached script you can see that when giving a timerange which does not start at 0 and end at maxint the queries get - 400% slower. - + 300% slower. python sample_timerange_query.py DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([]) PLAN: [0, 0, u'TABLE event WITH INDEX event_actor ORDER BY'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.080176s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.080375s DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view WHERE (timestamp = ? AND timestamp = ?) GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([u'1', u'5']) PLAN: [0, 0, u'TABLE event WITH INDEX event_timestamp'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.260648s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.260838s The reason is simply that the second query uses the 'wrong' index. -- find_event() queries with timerange other than TimeRange.always() are slow https://bugs.launchpad.net/bugs/672965 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: When running the attached script you can see that when giving a timerange which does not start at 0 and end at maxint the queries get 300% slower. python sample_timerange_query.py DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([]) PLAN: [0, 0, u'TABLE event WITH INDEX event_actor ORDER BY'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.080176s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.080375s DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view WHERE (timestamp = ? AND timestamp = ?) GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([u'1', u'5']) PLAN: [0, 0, u'TABLE event WITH INDEX event_timestamp'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.260648s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.260838s The reason is simply that the second query uses the 'wrong' index. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Merge] lp:~thekorn/zeitgeist/fix-672965-opt_timerange_queries into lp:zeitgeist
Markus Korn has proposed merging lp:~thekorn/zeitgeist/fix-672965-opt_timerange_queries into lp:zeitgeist. Requested reviews: Zeitgeist Framework Team (zeitgeist) Related bugs: #672965 find_event() queries with timerange other than TimeRange.always() are slow https://bugs.launchpad.net/bugs/672965 Made FindEvent queries faster if a timerange other than TimeRange.always() is used (LP: #672965) This is achieved by forcing the query planner to not use the timestamp index for this kind of queries by using the unary '+' operator. (see http://www.sqlite.org/optoverview.html section 6.0) -- https://code.launchpad.net/~thekorn/zeitgeist/fix-672965-opt_timerange_queries/+merge/40412 Your team Zeitgeist Framework Team is requested to review the proposed merge of lp:~thekorn/zeitgeist/fix-672965-opt_timerange_queries into lp:zeitgeist. === modified file '_zeitgeist/engine/main.py' --- _zeitgeist/engine/main.py 2010-10-25 09:48:49 + +++ _zeitgeist/engine/main.py 2010-11-09 11:12:51 + @@ -302,9 +302,9 @@ where = WhereClause(WhereClause.AND) min_time, max_time = time_range if min_time != 0: - where.add(timestamp = ?, min_time) + where.add(+timestamp = ?, min_time) if max_time != sys.maxint: - where.add(timestamp = ?, max_time) + where.add(+timestamp = ?, max_time) where.extend(self._build_sql_from_event_templates(templates)) === modified file '_zeitgeist/engine/sql.py' --- _zeitgeist/engine/sql.py 2010-10-25 20:26:03 + +++ _zeitgeist/engine/sql.py 2010-11-09 11:12:51 + @@ -47,6 +47,8 @@ @staticmethod def fix_unicode(obj): + if isinstance(obj, int): + return obj if isinstance(obj, str): obj = obj.decode(UTF-8) return unicode(obj) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 626492] Re: Log rar and zip files as archives
Added zeitgeist as affected since lp:libzeitgeist now pulls the mimetype mappings from there. Archive types we should recognize off the top of my head: tar, zip, and ar. We also have gz, bz2 which are not strictly archives, but just compression types, but I wouldn't object if we log them as archives because they are used as such in 99.9% of the cases I see. ** Also affects: zeitgeist Importance: Undecided Status: New -- Log rar and zip files as archives https://bugs.launchpad.net/bugs/626492 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Client Library: New Status in Zeitgeist Framework: New Bug description: rar and zip files are not logged as http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Archive This should be done though :) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
Re: [Zeitgeist] [Merge] lp:~thekorn/zeitgeist/fix-672965-opt_timerange_queries into lp:zeitgeist
The question which came in my mind after changing the code was: does the performance of other queries suffer from this change, so I changed the script attached to the bug to test all ResultType Before the change: --- LeastPopularActor: get len(ids)=6 using .find_eventids() in 0.078450s --- LeastPopularActor: get len(ids)=6 using .find_eventids() in 0.261053s ++ LeastPopularActor 332.763498996 --- LeastPopularMimeType: get len(ids)=1 using .find_eventids() in 0.066008s --- LeastPopularMimeType: get len(ids)=1 using .find_eventids() in 0.206841s ++ LeastPopularMimeType 313.35702779 --- LeastPopularOrigin: get len(ids)=1 using .find_eventids() in 0.200927s --- LeastPopularOrigin: get len(ids)=1 using .find_eventids() in 0.257056s ++ LeastPopularOrigin 127.935007932 --- LeastPopularSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.065896s --- LeastPopularSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.207888s ++ LeastPopularSubjectInterpretation 315.479743982 --- LeastPopularSubjects: get len(ids)=6 using .find_eventids() in 0.721558s --- LeastPopularSubjects: get len(ids)=6 using .find_eventids() in 0.774241s ++ LeastPopularSubjects 107.301266111 --- LeastRecentActor: get len(ids)=6 using .find_eventids() in 0.071438s --- LeastRecentActor: get len(ids)=6 using .find_eventids() in 0.258033s ++ LeastRecentActor 361.19819913 --- LeastRecentEvents: get len(ids)=6 using .find_eventids() in 0.133322s --- LeastRecentEvents: get len(ids)=6 using .find_eventids() in 0.247588s ++ LeastRecentEvents 185.706902626 --- LeastRecentMimeType: get len(ids)=1 using .find_eventids() in 0.064972s --- LeastRecentMimeType: get len(ids)=1 using .find_eventids() in 0.211424s ++ LeastRecentMimeType 325.407228279 --- LeastRecentOrigin: get len(ids)=1 using .find_eventids() in 0.172430s --- LeastRecentOrigin: get len(ids)=1 using .find_eventids() in 0.234929s ++ LeastRecentOrigin 136.246031658 --- LeastRecentSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.055954s --- LeastRecentSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.185784s ++ LeastRecentSubjectInterpretation 332.029758658 --- LeastRecentSubjects: get len(ids)=6 using .find_eventids() in 0.488676s --- LeastRecentSubjects: get len(ids)=6 using .find_eventids() in 0.537375s ++ LeastRecentSubjects 109.965477134 --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.069163s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.224269s ++ MostPopularActor 324.261352472 --- MostPopularMimeType: get len(ids)=1 using .find_eventids() in 0.056728s --- MostPopularMimeType: get len(ids)=1 using .find_eventids() in 0.186340s ++ MostPopularMimeType 328.480587054 --- MostPopularOrigin: get len(ids)=1 using .find_eventids() in 0.176185s --- MostPopularOrigin: get len(ids)=1 using .find_eventids() in 0.221803s ++ MostPopularOrigin 125.892285645 --- MostPopularSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.057706s --- MostPopularSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.179496s ++ MostPopularSubjectInterpretation 311.053314383 --- MostPopularSubjects: get len(ids)=6 using .find_eventids() in 0.617611s --- MostPopularSubjects: get len(ids)=6 using .find_eventids() in 0.685492s ++ MostPopularSubjects 110.990917401 --- MostRecentActor: get len(ids)=6 using .find_eventids() in 0.062013s --- MostRecentActor: get len(ids)=6 using .find_eventids() in 0.218987s ++ MostRecentActor 353.129925952 --- MostRecentEvents: get len(ids)=6 using .find_eventids() in 0.128710s --- MostRecentEvents: get len(ids)=6 using .find_eventids() in 0.256136s ++ MostRecentEvents 199.00231361 --- MostRecentMimeType: get len(ids)=1 using .find_eventids() in 0.064722s --- MostRecentMimeType: get len(ids)=1 using .find_eventids() in 0.216302s ++ MostRecentMimeType 334.201220051 --- MostRecentOrigin: get len(ids)=1 using .find_eventids() in 0.172238s --- MostRecentOrigin: get len(ids)=1 using .find_eventids() in 0.229335s ++ MostRecentOrigin 133.149875626 --- MostRecentSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.064796s --- MostRecentSubjectInterpretation: get len(ids)=1 using .find_eventids() in 0.211639s ++ MostRecentSubjectInterpretation 326.623591661 --- MostRecentSubjects: get len(ids)=6 using .find_eventids() in 0.574415s --- MostRecentSubjects: get len(ids)=6 using .find_eventids() in 0.620583s ++ MostRecentSubjects 108.03736898 --- OldestActor: get len(ids)=6 using .find_eventids() in 0.187836s --- OldestActor: get len(ids)=6 using .find_eventids() in 0.363429s ++ OldestActor 193.482187396 After the change: --- LeastPopularActor: get len(ids)=6 using .find_eventids() in 0.067574s --- LeastPopularActor: get len(ids)=6 using .find_eventids() in 0.073416s ++ LeastPopularActor 108.645290129 --- LeastPopularMimeType: get len(ids)=1 using .find_eventids() in
Re: [Zeitgeist] [Merge] lp:~thekorn/zeitgeist/fix-672965-opt_timerange_queries into lp:zeitgeist
A few comments: * I am not convinced that the perceived improvement is statistically significant. I haven't done the number crunching, but it's a bit fishy... * I'd really like to understand *why* it's bad to use the time index here and why sqlite goes on to use it? Does running ANALYZE (rebuilding the selectivity stats of the indexes) on the db improve things? -- https://code.launchpad.net/~thekorn/zeitgeist/fix-672965-opt_timerange_queries/+merge/40412 Your team Zeitgeist Framework Team is requested to review the proposed merge of lp:~thekorn/zeitgeist/fix-672965-opt_timerange_queries into lp:zeitgeist. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 672965] Re: find_event() queries with timerange other than TimeRange.always() are slow
** Changed in: zeitgeist Status: New = In Progress ** Changed in: zeitgeist Assignee: (unassigned) = Markus Korn (thekorn) ** Changed in: zeitgeist Importance: Undecided = Low ** Changed in: zeitgeist Milestone: None = 0.7.0 -- find_event() queries with timerange other than TimeRange.always() are slow https://bugs.launchpad.net/bugs/672965 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: In Progress Bug description: When running the attached script you can see that when giving a timerange which does not start at 0 and end at maxint the queries get 300% slower. python sample_timerange_query.py DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([]) PLAN: [0, 0, u'TABLE event WITH INDEX event_actor ORDER BY'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.080176s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.080375s DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view WHERE (timestamp = ? AND timestamp = ?) GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([u'1', u'5']) PLAN: [0, 0, u'TABLE event WITH INDEX event_timestamp'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.260648s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.260838s The reason is simply that the second query uses the 'wrong' index. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 626492] Re: Log rar and zip files as archives
** Branch linked: lp:~kamstrup/zeitgeist/extra-mimes -- Log rar and zip files as archives https://bugs.launchpad.net/bugs/626492 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Client Library: New Status in Zeitgeist Framework: New Bug description: rar and zip files are not logged as http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Archive This should be done though :) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 602211] Re: Monitoring Create/Move/Copy Files events
OK I think we can just add 1 column that links to the new uri in the uri table so it becomes id | uri | new_id so i i have a uri xxx 1 | xxx | 1 if its moved or renamed from xxx to yyy we have 1 | xxx | 2 2 | yyy | 2 OR we can do it the other way round by having the new column reference to its old_uri 1 | xxx | 1 2 | yyy | 1 ideas anyone ? -- 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 :) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 670355] Re: dynamic loading of extensions
ok since we already have 3* -1 I am changing the bug to won' fix ** Changed in: zeitgeist Status: New = Won't Fix -- dynamic loading of extensions https://bugs.launchpad.net/bugs/670355 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: Won't Fix Bug description: When wanting to use a new extension one has to restart zeitgeist. Problem with that is that all monitors are then gone. My suggestion would be to be able to dynamically load extension by monitoring the extensions directories and pulling in the new extension on runtime. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 626492] Re: Log rar and zip files as archives
** Changed in: zeitgeist Assignee: (unassigned) = Mikkel Kamstrup Erlandsen (kamstrup) ** Changed in: zeitgeist Status: New = In Progress ** Changed in: zeitgeist Milestone: None = 0.7.0 -- Log rar and zip files as archives https://bugs.launchpad.net/bugs/626492 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Client Library: New Status in Zeitgeist Framework: In Progress Bug description: rar and zip files are not logged as http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Archive This should be done though :) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Merge] lp:~kamstrup/zeitgeist/extra-mimes into lp:zeitgeist
Mikkel Kamstrup Erlandsen has proposed merging lp:~kamstrup/zeitgeist/extra-mimes into lp:zeitgeist. Requested reviews: Zeitgeist Framework Team (zeitgeist) Related bugs: #626492 Log rar and zip files as archives https://bugs.launchpad.net/bugs/626492 Adds a bunch of extra mimetype mappings and an URI scheme for ftp://. Please see commit log for details. -- https://code.launchpad.net/~kamstrup/zeitgeist/extra-mimes/+merge/40421 Your team Zeitgeist Framework Team is requested to review the proposed merge of lp:~kamstrup/zeitgeist/extra-mimes into lp:zeitgeist. === modified file 'zeitgeist/mimetypes.py' --- zeitgeist/mimetypes.py 2010-09-04 08:10:11 + +++ zeitgeist/mimetypes.py 2010-11-09 12:23:45 + @@ -3,6 +3,7 @@ # Zeitgeist # # Copyright © 2010 Markus Korn thek...@gmx.de +# 2010 Canonical Ltd # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU Lesser General Public License as published by @@ -123,7 +124,6 @@ application/javascript: Interpretation.SOURCE_CODE, application/x-csh: Interpretation.SOURCE_CODE, application/x-designer: Interpretation.SOURCE_CODE, -application/x-desktop: Interpretation.SOURCE_CODE, application/x-dia-diagram: Interpretation.SOURCE_CODE, application/x-fluid: Interpretation.SOURCE_CODE, application/x-glade: Interpretation.SOURCE_CODE, @@ -167,6 +167,28 @@ text/x-vala: Interpretation.SOURCE_CODE, text/x-vhdl: Interpretation.SOURCE_CODE, text/x-m4: Interpretation.SOURCE_CODE, + +# Arhcives +application/zip: Interpretation.ARCHIVE, +application/x-gzip: Interpretation.ARCHIVE, +application/x-bzip: Interpretation.ARCHIVE, +application/x-lzma: Interpretation.ARCHIVE, +application/x-archive: Interpretation.ARCHIVE, +application/x-7z-compressed: Interpretation.ARCHIVE, +application/x-bzip-compressed-tar: Interpretation.ARCHIVE, +application/x-lzma-compressed-tar: Interpretation.ARCHIVE, +application/x-compressed-tar: Interpretation.ARCHIVE, + +# Software and packages +application/x-deb: Interpretation.SOFTWARE, +application/x-rpm: Interpretation.SOFTWARE, +application/x-ms-dos-executable: Interpretation.SOFTWARE, +application/x-executable: Interpretation.SOFTWARE, +application/x-desktop: Interpretation.SOFTWARE, + +# File systems +application/x-cd-image: Interpretation.FILESYSTEM_IMAGE, + } MIMES_REGEX = make_regex_tuple( @@ -197,4 +219,5 @@ (https://;, Manifestation.FILE_DATA_OBJECT.REMOTE_DATA_OBJECT), (ssh://, Manifestation.FILE_DATA_OBJECT.REMOTE_DATA_OBJECT), (sftp://;, Manifestation.FILE_DATA_OBJECT.REMOTE_DATA_OBJECT), +(ftp://;, Manifestation.FILE_DATA_OBJECT.REMOTE_DATA_OBJECT), )) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 673008] [NEW] Reinstall monitors upon startup
Public bug reported: When for some reason zeitgeist restarts all monitors are then gone Quoting kamstrup: And fwiw - libzeitgeist detects when the daemon comes and goes and reinstates any monitors it has running - so restarting the daemon is not an issue for libzeitgeist customers We should look into having that in the python and zeitgeist-sharp wrappers ** Affects: zeitgeist Importance: Undecided Status: New ** Affects: zeitgeist-sharp Importance: Undecided Status: New ** Also affects: zeitgeist-sharp Importance: Undecided Status: New -- Reinstall monitors upon startup https://bugs.launchpad.net/bugs/673008 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: New Status in Zeitgeist Sharp: New Bug description: When for some reason zeitgeist restarts all monitors are then gone Quoting kamstrup: And fwiw - libzeitgeist detects when the daemon comes and goes and reinstates any monitors it has running - so restarting the daemon is not an issue for libzeitgeist customers We should look into having that in the python and zeitgeist-sharp wrappers ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 672315] Re: zeitgeist-datasources PPA only for amd64
** Project changed: zeitgeist = zeitgeist-dataproviders -- zeitgeist-datasources PPA only for amd64 https://bugs.launchpad.net/bugs/672315 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Data-Sources. Status in Zeitgeist Data-Sources: New Bug description: The only files available in the PPA are for amd64: https://launchpad.net/~zeitgeist/+archive/ppa http://ppa.launchpad.net/zeitgeist/ppa/ubuntu/pool/main/z/zeitgeist-datasources/ zeitgeist-datasource-geany_0.1.0~bzr20101102-0~ppa1_amd64.deb 02-Nov-2010 23:3021K zeitgeist-datasource-totem_0.1.0~bzr20101102-0~ppa1_amd64.deb 02-Nov-2010 23:3014K zeitgeist-datasource-vim_0.1.0~bzr20101102-0~ppa1_amd64.deb 02-Nov-2010 23:29 3.4K zeitgeist-datasources_0.1.0~bzr20101102-0~ppa1.dsc 02-Nov-2010 23:16 1.7K zeitgeist-datasources_0.1.0~bzr20101102-0~ppa1.tar.gz 02-Nov-2010 23:16 380K ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 670039] Re: missing handle copy/rename/move events
*** This bug is a duplicate of bug 602211 *** https://bugs.launchpad.net/bugs/602211 ** This bug has been marked a duplicate of bug 602211 Monitoring Create/Move/Copy Files events * You can subscribe to bug 602211 by following this link: https://bugs.launchpad.net/zeitgeist/+bug/602211/+subscribe -- missing handle copy/rename/move events https://bugs.launchpad.net/bugs/670039 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: With some work being done from the taskview side we will be able to tracker files move/renamed/copied Currently I suggest adding event interpretations for these events. However I am interested in figuring out how we want to make it reflect on the developers. If a file has been moved then the old subject uris are not usable. How can we tell the developers that it was moved? 1) Change the subject_uri in the uri table 2) Add a table mapping ids to subject_uris with the last entry of a subject_uri being the latest destination 3) Create a logic that interprets the move events when queries of type find_events are triggered and overwrite the subject_uris on return. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Translation template import - zeitgeist in Zeitgeist Framework 0.1
Hello Zeitgeist Framework Team, On 2010-11-09 13:09z (4 minutes ago), you uploaded a translation template for zeitgeist in Zeitgeist Framework 0.1 in Launchpad. The template has now been imported successfully. Thank you, The Launchpad team ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
Re: [Zeitgeist] [Bug 602211] Re: Monitoring Create/Move/Copy Files events
2010/11/9 Seif Lotfy 602...@bugs.launchpad.net: 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 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 :) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 672965] Re: find_event() queries with timerange other than TimeRange.always() are slow
** Also affects: zeitgeist/0.7 Importance: Low Assignee: Markus Korn (thekorn) Status: In Progress -- find_event() queries with timerange other than TimeRange.always() are slow https://bugs.launchpad.net/bugs/672965 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: In Progress Status in Zeitgeist Framework 0.7 series: In Progress Bug description: When running the attached script you can see that when giving a timerange which does not start at 0 and end at maxint the queries get 300% slower. python sample_timerange_query.py DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([]) PLAN: [0, 0, u'TABLE event WITH INDEX event_actor ORDER BY'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.080176s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.080375s DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view WHERE (timestamp = ? AND timestamp = ?) GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([u'1', u'5']) PLAN: [0, 0, u'TABLE event WITH INDEX event_timestamp'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.260648s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.260838s The reason is simply that the second query uses the 'wrong' index. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Blueprint get-state] Get state of User Activity
Blueprint changed by Alex Launi: Whiteboard changed: --- seif 2010-10-27 10:28pm --- Lets discuss this idea. Do we want it as a supported extension or do we want to have in the engine. Or do we want it as a community extension? How relevant is that to our current work? How could it help Unity and others? --- thekorn 2010-10-28 09:09 am --- I like the overall idea of making it easier to query for all open/active subjects at a given timestamp. Without commenting on the code you already have in the branch which is linked to this blueprint, I think we should develop the functionality as an external/community extension first. And once everything is polished, and working well enough we should decide whether we would like to have it as an (in-zeitgeist) extension or as part of the engine API. + --- alexlauni 2010-11-09 10:23 am --- + Being able to get relevancy info for what is happening *now* would be fantastic. It seems like this allows an amount of projection into what the user will be doing in the near future, which is obviously immensely powerful. -- Get state of User Activity https://blueprints.launchpad.net/zeitgeist/+spec/get-state ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 602211] Re: Monitoring Create/Move/Copy Files events
** Changed in: zeitgeist Assignee: (unassigned) = Seif Lotfy (seif) ** Changed in: zeitgeist-datahub Status: Incomplete = New -- 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: New 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
[Zeitgeist] [Bug 673008] Re: Reinstall monitors upon startup
** Changed in: zeitgeist Status: New = Confirmed -- Reinstall monitors upon startup https://bugs.launchpad.net/bugs/673008 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 Sharp: New Bug description: When for some reason zeitgeist restarts all monitors are then gone Quoting kamstrup: And fwiw - libzeitgeist detects when the daemon comes and goes and reinstates any monitors it has running - so restarting the daemon is not an issue for libzeitgeist customers We should look into having that in the python and zeitgeist-sharp wrappers ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
Re: [Zeitgeist] [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 rai...@ubuntu.comwrote: 2010/11/9 Seif Lotfy 602...@bugs.launchpad.net: 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 :) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 672965] Re: find_event() queries with timerange other than TimeRange.always() are slow
** Branch linked: lp:~thekorn/zeitgeist/fix-672965-opt_timerange_queries -- find_event() queries with timerange other than TimeRange.always() are slow https://bugs.launchpad.net/bugs/672965 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: In Progress Bug description: When running the attached script you can see that when giving a timerange which does not start at 0 and end at maxint the queries get 300% slower. python sample_timerange_query.py DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([]) PLAN: [0, 0, u'TABLE event WITH INDEX event_actor ORDER BY'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.080176s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.080375s DEBUG:zeitgeist.sql:Got query: QUERY: SELECT DISTINCT id FROM event_view WHERE (timestamp = ? AND timestamp = ?) GROUP BY actor ORDER BY COUNT(actor) DESC, timestamp DESC LIMIT 6 ([u'1', u'5']) PLAN: [0, 0, u'TABLE event WITH INDEX event_timestamp'] DEBUG:zeitgeist.engine:Found 6 event IDs in 0.260648s --- MostPopularActor: get len(ids)=6 using .find_eventids() in 0.260838s The reason is simply that the second query uses the 'wrong' index. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] ken-vandine joined zeitgeist-dataproviders
Hello Zeitgeist Framework Team, Ken VanDine (ken-vandine) has been added as a member of Zeitgeist Data- Sources Team (zeitgeist-dataproviders) by Seif Lotfy (seif). Follow the link below for more details. https://launchpad.net/~zeitgeist-dataproviders/+member/ken-vandine -- You received this email because you are an admin of the Zeitgeist Data-Sources Team team via the Zeitgeist Framework Team team. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Gnome-zeitgeist] [Bug 561860] Re: Activity Journal's Right-Click Delete Functionality Broken
Recently i noticed that i encounter this problem for example with Bzr events: if i commit 2 times on the same branch, i get only one event in GAJ. That is due to the fact that the two commit-event have the same uri... Imho GAJ should display these 2 events separately for example comparing if the text property is different... If you agree i could assign this bug to me... -- Activity Journal's Right-Click Delete Functionality Broken https://bugs.launchpad.net/bugs/561860 You received this bug notification because you are a member of GNOME Zeitgeist Team, which is the registrant for GNOME Activity Journal. Status in GNOME Activity Journal: In Progress Status in Zeitgeist Framework: Fix Released Bug description: Description of problem: Activity Journal's right-click delete functionality is broken. Version-Release number of selected component (if applicable): 0.3.3 How reproducible: 100% Steps to Reproduce: 1. Launch the Activity Journal. 2. Right-click on an item. 3. From the context menu that appears, choose to delete the item from the journal. Actual results: Nothing happens. Expected results: Item's entry should be removed. Reported in Fedora 13 against gnome-activity-journal-0.3.3-1.fc13.noarch. https://bugzilla.redhat.com/show_bug.cgi?id=579144 ___ Mailing list: https://launchpad.net/~gnome-zeitgeist Post to : gnome-zeitge...@lists.launchpad.net Unsubscribe : https://launchpad.net/~gnome-zeitgeist More help : https://help.launchpad.net/ListHelp
Re: [Gnome-zeitgeist] [Bug 561860] Re: Activity Journal's Right-Click Delete Functionality Broken
Are you setting the timestamp correctly? -- Activity Journal's Right-Click Delete Functionality Broken https://bugs.launchpad.net/bugs/561860 You received this bug notification because you are a member of GNOME Zeitgeist Team, which is the registrant for GNOME Activity Journal. Status in GNOME Activity Journal: In Progress Status in Zeitgeist Framework: Fix Released Bug description: Description of problem: Activity Journal's right-click delete functionality is broken. Version-Release number of selected component (if applicable): 0.3.3 How reproducible: 100% Steps to Reproduce: 1. Launch the Activity Journal. 2. Right-click on an item. 3. From the context menu that appears, choose to delete the item from the journal. Actual results: Nothing happens. Expected results: Item's entry should be removed. Reported in Fedora 13 against gnome-activity-journal-0.3.3-1.fc13.noarch. https://bugzilla.redhat.com/show_bug.cgi?id=579144 ___ Mailing list: https://launchpad.net/~gnome-zeitgeist Post to : gnome-zeitge...@lists.launchpad.net Unsubscribe : https://launchpad.net/~gnome-zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 602211] Re: Monitoring Create/Move/Copy Files events
New db_layout: uri_id (p) | lookup_id (f) | new_uri_id | old_uri_id | - 1 | 1234 | 2 | -1 2 | 1235 | -1 | 1 3 | 1234 | -1 | -1 Lookup Table: id - uri: lookup_id (p) | value --- 1234 | foo.txt 1235 | bar.txt (p) - primary key (f) - foreign key This solves the previous mentioned problems, but breaks compatibility with the old db schema. It don't know, how SQLite actually optimise the old schema, but I think a good DBMS should do this already. -- 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: New Status in Zeitgeist Framework: Confirmed Status in Zeitgeist Datahub: New 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
[Zeitgeist] [Bug 602211] Re: Monitoring Create/Move/Copy Files events
** Also affects: unity Importance: Undecided Status: New -- 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: New 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
[Zeitgeist] [Bug 602211] Re: Monitoring Create/Move/Copy Files events
OK what would happen if we use our uri table as our lookup table and add the above table as the uri_tracking_table Another though would be actually to have the normal uri_table and a new update_uri_table where we link and id to its new id so moving foo to bar will give us id | value --- 1 | foo.txt 2 | bar.txt id | new_value_id --- 1 | 2 now in case we move bar.txt to lol.txt we just update the DB again by checking the all value_ids = 2 and change it to 3 and add a new row... id | value --- 1 | foo.txt 2 | bar.txt 3 | lol.txt id | new_value_id --- 1 | 3 2 | 3 so if the user asks for raw events we do what we always did if the user asks for updated events (updated subject_uris) we will need to join once... It comes with a cost of performance but I think we can handle it We need to actually sprint on that issue. I marked this as effecting Unity since when I move a file i don see it in unity anymore -- 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: New 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
[Zeitgeist] [Bug 612344] Re: Blacklist API sucks
At some point people will need to blacklist over Unity. I think that should be taken in consideration in the new design and development cycle. Example: What if I don't want my .py files to show up in Unity ** Also affects: unity Importance: Undecided Status: New -- Blacklist API sucks https://bugs.launchpad.net/bugs/612344 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Unity: New Status in Zeitgeist Framework: Triaged Bug description: Guys, GetBlacklist and SetBlacklist (without any signals) for an asynchrounous-by-nature API? Come on! How about changing it to Get, Add, Remove and a changed signal? That way it'd be actually usable... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
