Change filter value for null choices

[jeremystretch]

Environment

• Python version: 3.5.2
• NetBox version: 2.4.8

Proposed Functionality

Currently, filtering for a null value uses the integer zero. For example, to find all devices not assigned to a rack, you would filter for:

/dcim/devices/?rack_id=0

I am proposing that we change this value to the string null:

/dcim/devices/?rack_id=null

This change involves removing the following two lines in settings.py (null is the default choice value):

FILTERS_NULL_CHOICE_LABEL = 'None'
FILTERS_NULL_CHOICE_VALUE = '0'

While this is a simple change, it is fairly disruptive, particularly to API consumers, and should be well communicated upon implementation.

Use Case

Using 0 to represent a null value works fine for ForeignKey fields, however it causes problems when filtering on BooleanFields, as was raised in #2357. I'm not sure why we went with 0 originally. I want to say that it was because earlier versions of the django-filter library didn't have built-in support for null filtering but I could be wrong.

Database Changes

None

External Dependencies

None

[jvanderaa]

This would not be disruptive to anything that I have at this moment. None is a good representation.

[mmahacek]

I was about to ask "Why not both" until I saw the part about boolean fields. I am not using any API calls to filter for null values, so this wouldn't be an issue for me.

[lampwins]

I am in favor of this change. I would also say this is merely a "breaking change" to something that is already broken.

@jeremystretch pertaining to communication, do you think it is too late to squeeze this into v2.5?

[jeremystretch]

Yeah, let's knock it out in v2.5. It's not terribly disruptive, and should be a trivial change for situations where it causes problems. I'd like to take a look at revamping query filters in the near future, and this is a blocker for that work.

[DanSheps]

I would say what if you deprecated it in 2.5.0 and remove it in 2.5.5 (or whatever arbitrary version) where null filters and 0 filters.

If this is not possible to deprecated (because it requires x amount of new code to check for both) then I would be in favour of just doing it in 2.5.0