Search for FQDN

[squintfox]

So something I'm struggling with is if you have:

Zone: domain.name
Record: www

NetBox search can find "www" or it can find "domain.name", but it can't find "www.domain.name". Looking at the code, the data is there as display_name, but that doesn't seem to be a database field, rather calculated and I don't think you can add it to the search index.

Is this something that's next to impossible or is it a reasonable idea for a feature? I'm unsure about the underlying possible problems.

[peteeckel]

Hi @squintfox, I don't think that's a problem - good idea, thanks!

I'll look into it in the next few days.

[squintfox]

@peteeckel Thanks for being the best of OSS. That's awesome.

[peteeckel]

Hi @squintfox, thanks for the praise, but I guess there's some humble pie to eat for me :-)

NetBox search can find "www" or it can find "domain.name", but it can't find "www.domain.name". Looking at the code, the data is there as display_name, but that doesn't seem to be a database field, rather calculated and I don't think you can add it to the search index.

Unfortunately, this is correct. I had some hope that it can be worked around with an annotation, but the code actually does not work with annotations ... _meta.get_field(field_name) does not work with annotations, just with 'real' fields. That it doesn't work with attributes of the ORM was to be expected, but unfortunately it is really limited to a real model field.

So currently the only option to get the global search to work with FQDN seems to be to denormalise the database model and store the FQDN in the record as a derived field. This is really messy so I'd like to avoid it at almost all cost.

However, all is not lost, at least not for all times. Looking at the Django 5.0 release notes you'll find this. The general idea is to reimplement the fqdn() method in SQL (which is, unfortunately, not completely trivial as well), and that way create a derived field in Django that will then be supported by the global search index without having to denormalise anything.

And no, that's not really a short-term solution. Currently, derived fields have some limitations, for instance this

    fqdn_test = models.GeneratedField(
        expression=F('zone__name'),
        output_field=models.CharField(),
        db_persist = True,
    )

does not work because zone__name is not permitted:

django.core.exceptions.FieldError: Joined field references are not permitted in this query

but I hope that it can be done with as_sql().

Bottom line: It can't be done with reasonable effort until NetBox 4.0.0 is released. And even then it's a bit of work, but should hopefully be feasible eventually.

[squintfox]

@peteeckel Thanks for all this work. Bummer, but sounds hopeful for 4.0. :)

[peteeckel]

And now it's finally there ... not implemented in SQL, and actually before the arrival of NetBox 4. It will be in the next 0.22.x release (and of course in 1.0.0 as well :-)).

[squintfox]

@peteeckel Well that's just fantastic. Thank you, good sir.