Sort by IP behaviour (examples within)

Post your feature requests here
Post Reply
fdeas
Posts: 2
Joined: Sat Oct 02, 2021 9:27 am

Sat Oct 02, 2021 10:01 am

Currently sorting by IP address doesn't really sort properly if you have a mix of one, two or three digit ending IPs

Example, instead of this
10.0.0.1
10.0.0.2
10.0.0.10
10.0.0.20
10.0.0.100
10.0.0.200

You get this
10.0.0.1
10.0.0.10
10.0.0.100
10.0.0.2
10.0.0.20
10.0.0.200

Its a small QoL change but it would be nice! Would you please consider changing this behaviour? or giving the option to toggle between behaviours?

Thanks in advance
Vik@Unimus
Posts: 18
Joined: Thu Aug 05, 2021 6:35 pm

Mon Oct 04, 2021 4:24 pm

Hello and Welcome to our forum,

Thank you for the suggestion, we agree and we have already created an internal ticket to implement sorting for IPs and it is in our development backlog.

At this moment, however, I don't any ETA for it, but I added this topic to our ticket and will update this topic once we have it ready.
User avatar
Tomas
Posts: 1022
Joined: Sat Jun 25, 2016 12:33 pm

Mon Oct 04, 2021 8:25 pm

Just to provide a bit more information, since this might seem like it's something easy to fix, but this is actually quite a complex problem. To elaborate:

Unimus supports entering device addresses in many formats:
- FQDN
- hostname
- IPv4 address
- IPv6 address

All of these can be present in the devices table, and sorting has to work "somehow" for all of them. We can't use simple numeric sorting, due to the mix of formats. There is a sorting method that exists that will cover all of these, called "natural sorting". This comes with a problem tho.

Unimus currently supports 3 DB engines (HSQL, MySQL/MariaDB and PostgreSQL). We will be adding support for MSSQL soon too. Since sorting and paging is done on the DB layer, we need all the DBs to support the sorting method we choose. Sadly, natural sorting is not available in all of the DBs out-of-the-box. Each DB engine requires different and unique way to do natural sorting. This is problematic with our DB framework and the way we write our DB abstraction, since we don't want to write all DB queries for each DB engine manually.

To sum up - this is not a simple problem, and we don't have a good solution yet. We definitely want to fix this, but like Vik mentioned, don't have an ETA yet.
fdeas
Posts: 2
Joined: Sat Oct 02, 2021 9:27 am

Tue Oct 05, 2021 1:11 pm

Thanks for the detailed response... I should have guessed it wasn't easy!
Post Reply