Created attachment 538714 [details, diff] Map integer as integer Versions of a package are ordered based on a calculated `sort_key` value. This `sort_key` value is based on the package version number. There are tests on the repository explaining how one version compare to another: https://gitweb.gentoo.org/sites/packages.git/tree/test/lib/portage/util/versions_test.rb Based on this, it's expected that the kernel version 4.14 appears before the version 4.1 (reverse order) on the package version list, but if one visits https://packages.gentoo.org/packages/sys-kernel/gentoo-sources they would see 4.14.50 at the bottom of the list even though we have other older versions (4.1, 4.4, 4.9, etc.). I pulled the repository and ran it on my computer (thanks for the docker-compose file!) and I've noticed that while the sort keys are being correctly generated, the way we've created our index is causing elastic search to return them in a "random" order. Version.all(query: { match: { package: pkg.atom }}, sort: { sort_key: { order: 'asc' }}).map(&:sort_key) => [0, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 3, 30, 31, 32, 33, 4, 5, 6, 7, 8, 9] The reason why "10" is greater than "2" on this ordered list is because we are not telling ElasticSearch that we are storing integer values. I've attached the proposed change to address this.
(In reply to Bruno Pinto from comment #0) > Created attachment 538714 [details, diff] [details, diff] > Map integer as integer > > Versions of a package are ordered based on a calculated `sort_key` value. > This `sort_key` value is based on the package version number. > > There are tests on the repository explaining how one version compare to > another: > https://gitweb.gentoo.org/sites/packages.git/tree/test/lib/portage/util/ > versions_test.rb > > Based on this, it's expected that the kernel version 4.14 appears before the > version 4.1 (reverse order) on the package version list, but if one visits > https://packages.gentoo.org/packages/sys-kernel/gentoo-sources they would > see 4.14.50 at the bottom of the list even though we have other older > versions (4.1, 4.4, 4.9, etc.). > > I pulled the repository and ran it on my computer (thanks for the > docker-compose file!) and I've noticed that while the sort keys are being > correctly generated, the way we've created our index is causing elastic > search to return them in a "random" order. > > Version.all(query: { match: { package: pkg.atom }}, sort: { sort_key: { > order: 'asc' }}).map(&:sort_key) > => [0, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 21, 22, 23, 24, 25, > 26, 27, 28, 29, 3, 30, 31, 32, 33, 4, 5, 6, 7, 8, 9] > > The reason why "10" is greater than "2" on this ordered list is because we > are not telling ElasticSearch that we are storing integer values. > > I've attached the proposed change to address this. Thanks, this was merged and is in production now. -A
*** Bug 649318 has been marked as a duplicate of this bug. ***
