It's similar to the problem system-image-server had with more than 9 builds in a single day. It may have been easier for them to sort since it's Python code and they could have written a custom sort method.
Apparently the projectbuilds context object is created in projects/views.py, in ProjectBuildListView:
return sorted(qs, key=lambda x: [int(y) for y in x.split('.')])
This orders lists of integers which will behave as we want, with the downside that the elements of the build id *need* to be convertible to int. Example:
>>> sorted(('2010.1','2010.2','2010.10','2010.80'))
['2010.1', '2010.10', '2010.2', '2010.80'] # Bad ordering
>>> sorted(('2010.1','2010.2','2010.10','2010.80'), key=lambda x: [int(y) for y in x.split('.')])
['2010.1', '2010.2', '2010.10', '2010.80'] # This is good
However, as seen in that stackoverflow answer, this will not work on large sets of builds. The suggested solution, which I'd tend to agree with, is introducing an "order" column to use with order_by() directly in the query set. We could have a data migration which would apply the "split at the dots" for the build ID to populate this column, and then simply incrementally add to it.
It's similar to the problem system-image-server had with more than 9 builds in a single day. It may have been easier for them to sort since it's Python code and they could have written a custom sort method.
Apparently the projectbuilds context object is created in projects/views.py, in ProjectBuildLis tView:
def get_queryset(self): objects. filter(
project= self._get_ project_ from_url( ))
return ProjectBuild.
I'm not sure any order_by parameter would give us the order we want. This http:// stackoverflow. com/questions/ 883575/ custom- ordering- in-django suggests simply using Python ordering for smallish data sets:
qs = ProjectBuild. objects. filter(
project= self._get_ project_ from_url( ))
return sorted(qs, key=lambda x: [int(y) for y in x.split('.')])
This orders lists of integers which will behave as we want, with the downside that the elements of the build id *need* to be convertible to int. Example:
>>> sorted( ('2010. 1','2010. 2','2010. 10','2010. 80')) ('2010. 1','2010. 2','2010. 10','2010. 80'), key=lambda x: [int(y) for y in x.split('.')])
['2010.1', '2010.10', '2010.2', '2010.80'] # Bad ordering
>>> sorted(
['2010.1', '2010.2', '2010.10', '2010.80'] # This is good
However, as seen in that stackoverflow answer, this will not work on large sets of builds. The suggested solution, which I'd tend to agree with, is introducing an "order" column to use with order_by() directly in the query set. We could have a data migration which would apply the "split at the dots" for the build ID to populate this column, and then simply incrementally add to it.