Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with filters if filter value is Null #442

Open
VictorPavlushin opened this issue Jan 31, 2022 · 7 comments
Open

Problem with filters if filter value is Null #442

VictorPavlushin opened this issue Jan 31, 2022 · 7 comments
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application

Comments

@VictorPavlushin
Copy link
Contributor

VictorPavlushin commented Jan 31, 2022

Netbox - v3.1.6
pynetbox - 6.5.0
Repeatability I think on all versions.
Let's look at the request:
https://demo.netbox.dev/api/dcim/racks/?site_id=21&location_id=null
We'll get racks with no location.
If we try to do the same through the pynetbox library:
pynb.dcim.racks.filter(site_id=21, location_id=None)
Then we get all the racks on this site. The request will look like:
https://demo.netbox.dev/api/dcim/racks/?site_id=21
This applies to both the get request and all objects.

@markkuleinio
Copy link
Contributor

Use location_id="null" (see #380)

@VictorPavlushin
Copy link
Contributor Author

so i need to additionally keep track of the return value from the other request? It seems to me that this complicates and makes my code ugly.
instead of:
pynb.dcim.racks.filter(site_id=21, location=obj.location)
like this:
pynb.dcim.racks.filter(site_id=21, location=obj.location if obj.location else "null")
It's not pretty in my opinion

@markkuleinio
Copy link
Contributor

The problem/feature is apparently this (https://docs.python-requests.org/en/latest/user/quickstart/#passing-parameters-in-urls): "Note that any dictionary key whose value is None will not be added to the URL’s query string."

@zachmoody what do you think, could we change Request._make_call() to check for any None values and just replace them with "null"? Extra mention in release notes is probably needed.

@VictorPavlushin
Copy link
Contributor Author

VictorPavlushin commented Feb 3, 2022

By the way, if you substitute "null" in the filter, for example, in vrf_id, then there will be an error:
nb.ipam.prefixes.get(prefix=prefix.prefix, vrf_id=vrf)
pynetbox.core.query.RequestError: The request failed with code 400 Bad Request: {'vrf': ['Related objects must be referenced by numeric ID or by dictionary of attributes. Received an unrecognized value: null']}

@markkuleinio
Copy link
Contributor

I don't get why the error says about vrf while your .get() is using vrf_id.

What does your vrf variable contain?

Anyway, this is how it looks like here (pynetbox ~6.5.0, NetBox 3.2.0-dev):

>>> netbox.ipam.prefixes.get(prefix="10.1.1.0/24").vrf is None
True

>>> netbox.ipam.prefixes.get(prefix="10.2.2.0/24").vrf
TestVRF

>>> netbox.ipam.prefixes.get(prefix="10.1.1.0/24", vrf_id="null")
10.1.1.0/24

>>> netbox.ipam.prefixes.get(prefix="10.2.2.0/24", vrf_id="null")
(not found, correct)

@VictorPavlushin
Copy link
Contributor Author

Indeed, my mistake, the "null" value was passed to the "create" function: nb.ipam.prefixes.create(obj)

@zachmoody
Copy link
Contributor

@zachmoody what do you think, could we change Request._make_call() to check for any None values and just replace them with "null"? Extra mention in release notes is probably needed.

I don't know, I agree it is cleaner, but I also worry it could result in some astonishing behavior for clients. E.g. someone initializing a variable that winds up getting passed to get or filter as None now has very confusing result. I think the current behavior with null is worth calling out in the docs though.

@abhi1693 abhi1693 added status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application labels Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

4 participants