Zeitgeist Framework

Timestamp isn't considered when choosing events by popularity

Bug #772041 reported by Siegfried Gevatter on 2011-04-27

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Zeitgeist Framework	Fix Released	High	Unassigned	Zeitgeist Framework 0.8.0 "I only got a donkey"

Bug Description

Currently the MostPopular* and LeastPopular* methods are choosing a random (*) event from within all events matching the criteria.

Is this desired? I believe it'd make more sense to return that one with the highest timestamp for MostPopular* and the one with the oldest timestamp for LeastPopular*, or something along that lines (there are currently such "timestamp ASC/DESC" statements in the code, but they aren't working, so if we agree on this property they need to be fixed).

(* Actually, it's the last one which was inserted into the database, but that doesn't mean anything.)

Related branches

lp:~zeitgeist/zeitgeist/fix772041

Merged into lp:zeitgeist/0.1 at revision 1746

Markus Korn: Approve on 2011-05-04

lp:zeitgeist/0.1

lp:~zeitgeist-packagers/zeitgeist/debian

lp:debian/zeitgeist

lp:ubuntu/oneiric/zeitgeist

Siegfried Gevatter (rainct) on 2011-04-27

Changed in zeitgeist:
importance:	Undecided → High

Revision history for this message

Markus Korn (thekorn) wrote on 2011-04-28:

10:17 < thekorn> RainCT: so the bug is: COUNT(<boo>) is working, but the additional
                 sorting by timestamp is not?
10:18 < RainCT> thekorn: Right. So the question is if we want it to work (and if so I'll
                fix it together with a related bug)
10:19 < thekorn> RainCT: yes, we want it to work. picking them by timestamp makes sense,
                 and returning *random* results does not
10:19 < thekorn> it's also an issue in our tests that we don't see this bug
10:20 < RainCT> thekorn: OK, agreed.
10:20 < RainCT> So that this in the bug and I'll try to fix it tonight.
10:20 < thekorn> it's because we are inserting events presorted by timestamp
10:20 < RainCT> The tests are just looking at the envet ids, they should be looking at
                the timestamps instead.
10:21 < RainCT> (I already swapped the order of 2 events, so checking the timestamps
                will expose the problem)