As discussed on IRC, I don't really like how this is ending up. We should look 
into re-architecting FTS at some point, starting from the assumption that it's 
only for searching current documents (so it may change from storing all events 
to storing one of each subjects + event information, or whatever). But since 
this stuff is supposed to be working in Precise, I guess it's fine to go with 
the workaround for now.

The main problem I see with the MP right now is that it's just looking at the 
URI when re-requesting the events, so if the request was for something 
particular (especially event interpretation, event manifestation or actor, 
since the subject data could be seen as somewhat more constant) it's likely to 
end up giving a wrong sort of event.

A possible way of fixing this would be merging the uri templates with the 
request templates (the ones used in CompileEventFilterQuery). The trivial 
implementation would go something like:

tmpls = []
for template in templates:
  for uri in uris:
    tmpl = copy(template)
    tmpl.subject_uri = ...

However, it may end up generating really big SQL queries (eg. consider just two 
templates for subject_interpretation={Music,Video} and a limit of 100 events; 
that becomes 200 templates with subject_interpretation and 
subject_manifestation, which is 400 conditions in the generated SQL).
Your team Zeitgeist Framework Team is requested to review the proposed merge of 
lp:~mhr3/zeitgeist/fts-secondary-sorting into lp:zeitgeist.

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to