| Summary: | Sorting by "Variable" in the BitBake variables table is not working as expected | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Toaster | Reporter: | Belen Barros Pena <belen.barros.pena> |
| Component: | toaster | Assignee: | David Reyna <david.reyna> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | alexandru.damian, belen.barros.pena, cristiana.voicu, richard.purdie |
| Version: | unspecified | ||
| Target Milestone: | 1.6 M5 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Belen Barros Pena
2014-03-27 11:01:01 UTC
As near as I can tell, there is no way from Django to modify the sorting defaults for the "orderby" operator. I do not see how this can be fixed without resorting to custom sorting. The Django documentation specifically states: "There’s no way to specify whether ordering should be case sensitive. With respect to case-sensitivity, Django will order results however your database backend normally orders them." (https://docs.djangoproject.com/en/dev/ref/models/querysets) A custom sort would have to be executed before the paginator. Since the paginator instantiates the entire table anyway, there is no change in overhead in that respect. We would just not get the sorting efficiency of the database since our code would be in Python, but the data set is not that huge. This is a very minor thing, and the fix seems quite a lot of work, so marking as won't fix as per our last conversation during the weekly call. |