Import Devices - Required Fields list (Uniqueness)

[jifox]

Environment

• Python version: N/A
• Nautobot version: a7cd5067476b (v1.0.1b1)

Steps to Reproduce

1. open Devices List
2. Click on import

Expected Behavior

In my opinion the name field must be a required field to ensure a unique dataset

Observed Behavior

see screenshot

[glennmatthews]

Thanks for the report! Unfortunately there are use cases for un-named devices, as well as for devices whose names are locally (but not globally) unique, so I don't believe we'll be able to change this behavior without breaking those use cases.

[jifox]

@glennmatthews Than maybe adding the primary-key value to the export/import will help to select a unique record

[jathanism]

We might discuss how we can assert a unique identifier with the name field allowed to be null. In my opinion this could easily be solved by the introduction of a slug field that must be unique and cannot be null. This has come up in other contexts.

Ultimately this is a bigger issue, because the name field is use in "unique together" relationships for asserting uniqueness constraints (for example ("site", "tenant", "name") is one of them). This is actually flawed, because two objects with null fields are not equal because in SQL NULL != NULL, so it's possible to have two devices in the same site + tenant pair with null name fields... At least from the database perspective.

From a usability perspective, this behavior is surprising and undesirable because when exported NULL in SQL becomes null in JSON where null === null (or None in Python where None is None), so the ability to differentiate two objects with the same null name, with the same site + tenant IDs becomes impossible.

This complicates export, and import all the same without primary keys also being used. Using primary keys on import is also not desirable, because more often than not you want to be creating new objects that wouldn't have primary keys in the first place.

Coming up with a solution for this is going to take some time, and since it will introduce changes to the API, the data model, and therefore the database schema, it will have to be slated for a future release so that we can plan ahead.