What you see is the expected behavior. The issue with long-term data - compared with live data - is that we don't know which host name was associated to a client with the IP 192.168.0.123 five months ago. We have this information right now, however, many users use routers with non-deterministic DHCP servers that will hand out IP addresses sequentially depending on who comes first.
Arguably, we could store the host name instead of the IP address in the long-term database, however, this would
a) be a backwards incompatible change, and
b) might lead to mixed records when host names are only added later to already existing clients.
In the latter case, queries from one and the same device would be stored once with the IP address and once with the host name. We do not store both as the long-term database is already now a critically large database and adding this extra information for each query seems too much in terms of extra storage usage.
However, as always, I'm the one that writes code, I'm not the one that says in which direction the project needs to go. If I can be convinced to do something differently, we can surely do this
When I query the database, I see that some clients are resolved to their hostname. I suspect that these were IPv4 addresses and their hostname has been stored.
I used the search field to find wich client's IPv4 addresses are stored.
What I found was only one client/a wifi access point, wich doesn't get it's IP from the DHCP.
So it seems that for IPv4 addresses the client's hostname is stored in the db, but for IPv6 only the address.