On 11/04/2014 16:45, "Reyna, David" <david.reyna@windriver.com> wrote:

>> This seems to be working for the Outcome column. Does it also solve the
>> problem for the "Cache attempt" one?
>
>Yes! That is the "sstate_cache" value.

Excellent! :)

Thanks!

>
>- David
>
>> -----Original Message-----
>> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
>> Sent: Friday, April 11, 2014 8:14 AM
>> To: Reyna, David; DAMIAN, ALEXANDRU
>> Cc: toaster@yoctoproject.org
>> Subject: Re: [review-request] 5921 "Task outcomes are sorted by database
>> value, instead of alphabetically"
>>
>> On 11/04/2014 05:56, "Reyna, David" <david.reyna@windriver.com> wrote:
>>
>> >Hi Belén and Alex,
>> >
>> >I have completed 5921, using the technique of a python class Œproperty¹
>> >as a Œfield¹ together with an explicit python sort (instead of
>>Œsortby¹),
>> >as described in this web site. This general method can be used for any
>> >transient or synthesized value of a
>> > class instance.
>> >
>> >
>>
>>>http://blog.mattwoodward.com/2013/02/generating-and-sorting-on-transient
>>>.h
>> >tml
>>
>>><http://blog.mattwoodward.com/2013/02/generating-and-sorting-on-transien
>>>t.
>> >html>
>> >
>> >The branch is here: dreyna/outcome_sort_5921
>>
>> This seems to be working for the Outcome column. Does it also solve the
>> problem for the "Cache attempt" one?
>>
>> Cheers
>>
>> Belén
>>
>> >
>> >This patch handles both forward and reverse sorts, plus it handles the
>> >Œ-1¹ base for the outcome text table and the convention of using a
>>blank
>> >string for sstate_cache values of SSTATE_NA. The regular column sorts
>> >pass the regression test. I also ran the
>> > HTML Validator.
>> >
>> >- David
>> >
>> >
>>
>