← Back to team overview

zeitgeist team mailing list archive

[Bug 646124] Re: Wrong understanding of the LeastRecentActors

 

Exactly.
The current docstring matches the current returns. IMHO both are wrong according to my and Siegfried's definition of LeastRecentActor. I do agree with your proposal of changing the docstring to "The most recent event for each subject, ordered with the oldest events first". Because it will match our definition of LeastRecentSubject. My concern is if its a API break?

-- 
Wrong understanding of the LeastRecentActors
https://bugs.launchpad.net/bugs/646124
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:
In an attempt to work on bug #641968 I discovered that we some of us defer on the understanding of LeastRecentActor

The documentation stated that LeastRecentActor = enum_factory(("The first event of each different actor"))

Let's assume we have sequential events. (The actors are defined by numbers)

2, 1, 3, 2, 1, 4

So we have 4 different actors (1,2,3,4) and we want to sort them by least recent.
the least recent is not 2 or 1 since they are used again at the end. the least recent is 3

This means LeastRecentActors should return the latest actors sorted ASC:

3, 2, 1, 4

and not

2, 1, 3, 4

When we look at LeastRecentSubjects = enum_factory(("One event for each subject only, "
  "ordered with oldest events first"))
My understanding according to Siegfried is:

<seif_> RainCT,
<seif_> LeastRecentSubjects = enum_factory(("One event for each subject only, "
<seif_>   "ordered with oldest events first")
<seif_> so i f i have
<seif_> the subject
<seif_> 1, 2, 1, 3, 4
<seif_> what do i get returned
<seif_> 1, 2, 3, 4
<seif_> or
<seif_> 2, 1, 3, 4
<seif_> ?
<RainCT> seif_: the later
<RainCT> for each subject you only look at the most recent one
<seif_> ok then we should do the same for the actors :)
<RainCT> Yes. Isn't it like this already?
<seif_> no

In that case if we follow this convention I can update the doc strings and already have the bug fix for both this bug and #641968







References