Comment 0 for bug 778140

<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