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
Sort by IP behaviour (examples within)
-
Vik@Unimus
- Posts: 198
- Joined: Thu Aug 05, 2021 6:35 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.
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.
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.
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.
Hi,
Thank you for your kind reminder. We are aware of the longer waiting time, but as Tomas explained in his reply, the solution is quite complex and requires more time and resources, which we currently do not have. However, we will definitely revisit this topic during the reevaluation of our future content at the end of the year. If the situation changes, we will let you know, or this topic will be added to our Roadmap.
Thank you for your kind reminder. We are aware of the longer waiting time, but as Tomas explained in his reply, the solution is quite complex and requires more time and resources, which we currently do not have. However, we will definitely revisit this topic during the reevaluation of our future content at the end of the year. If the situation changes, we will let you know, or this topic will be added to our Roadmap.