zeitgeist team mailing list archive

[Siegfried Gevatter <rainct@xxxxxxxxxx>]

For 0.8.0 I'll be fixing the MOVE_EVENT handling to only rename events
with a timestamp older than that of the move event. The real fix could
be postponed for later, or considered for 0.8.0 if there's enough time.

** Changed in: zeitgeist
   Importance: Undecided => Medium

** Changed in: zeitgeist
       Status: New => Triaged

** Changed in: zeitgeist
     Assignee: (unassigned) => Siegfried Gevatter (rainct)

-- 
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
https://bugs.launchpad.net/bugs/778140

Title:
  MOVE_EVENT handling doesn't support unsorted events for the same uri

Status in Zeitgeist Framework:
  Triaged

Bug description:
  
  <RainCT> seiflotfy: the query updating current_uri on MOVE_EVENT should only change stuff with timestamp<move_event_timestamp
  <seiflotfy> RainCT, true
  <seiflotfy> good catch
  <RainCT> seiflotfy: there's also another ugly case
  <seiflotfy> RainCT, do tell
  <RainCT> seiflotfy: Imagine you insert event: 0. A, 1. A, 2. A, 3. B, 4. C, 5. A. Then with timestamp between events 3 and 4 you get A->T, so now you have "T, T, T, B, C, A"
  [...]
  <seiflotfy> i see the problem
  <seiflotfy> the last A should be a T
  <RainCT> no, the last A is fine
  <RainCT> because it is a new file with the same name
  [...]
  <seiflotfy> yeah ok
  <RainCT> seiflotfy: now you get A-L with timestamp between 1 and 2, so it should have "L, L, T, B, C, A", but since the current_uri of the first is already L you won't see it. for this it'd need to check the original URI instead of the current_uri
  <RainCT> are you with me so far?
  <seiflotfy> trying to
  <seiflotfy> RainCT, ok i cont get your last point
  <seiflotfy> A-L wont change the T
  <seiflotfy> because A has been move to T
  <seiflotfy> you can not move A again
  <seiflotfy> you need to move T
  <seiflotfy> thus its does not work
  <RainCT> yeah, but it should, because you're being told that it was moved before that
  <seiflotfy> unless you really want to you will have to look for all "MOVE_EVENTS" with A and figure out what A is now
  <seiflotfy> its doable
  <RainCT> so the move that happened later in time didn't affect those events, only the later ones
  <seiflotfy> RainCT, true
  <RainCT> the easy way to solve this is checking subj_id instead of subj_id_current
  <seiflotfy> RainCT, i think we should raise an exception
  <RainCT> but now when it gets really messed up is if there was even another move event before that
  <RainCT> which was already logged
  <seiflotfy> "You tried to move and event after it was used in a new location"
  <seiflotfy> RainCT, actually we also have the MOVE_EVENT logged
  <seiflotfy> you can then try to figrue out the patch of A
  <RainCT> yes, that's the solution
  <seiflotfy> the path
  <seiflotfy> RainCT, but i highly discourage that
  <RainCT> you can find the previos move event and set timestamp>previous_move_event.timestamp
  <seiflotfy> RainCT, exactly
  <seiflotfy> i am +- 0 on that tbh
  <seiflotfy> not sure
  <RainCT> ok, I don't dislike finding the previous timestamp
  <RainCT> i'll open a bug