Risks of modifying the id of a tenant in postgresSQL

[clearnano]

Hi,

This is mainly for the netbox dev teams. I'm looking to migrate existing data over to netbox and the existing data carries an id of 4000 and above. Would this be a wise idea interms of manipulating id in the postgresSQL after say created a tenantgroup and rather than the tenant group carrying an id of 1 to have it modified to 4000 and incrementing by one for each client from the old database. Few questions arise

• As the database grows is there a possiblility this would cause issues to the db in the near future as newer clients are added (not from DB) which would start with 1 and increment by 1 (2,3,4,)

• Also, what happens when netbox data was grew organically and then reaches modified data ex. 4000 would it skip it and increment to 4001?

• Another question is there a way to reset the db count say i deleted clients that were created with an id of 1 to 100 deleted these clients in client site; is there any way to restart from 1?

Many Thanks,

[candlerb]

Netbox database IDs are allocated via Postgres sequences. You can reset them (Google for how to do this); resetting a sequence to MAX(id)+1 is safe, as long as you're not inserting at the same time. But resetting it to a value lower than existing rows is just creating a ticking time bomb for yourself. It won't skip existing allocations.

You should consider Netbox IDs to be opaque, immutable, and not user-selectable. Use "slug" if you want to create a user-defined reference for an object (but unfortunately not all data models have slugs)

If this is a one-time migration, then importing the existing IDs 4000+ and then resetting the sequence to a value above this is just about conceivable. However, since this means you will be doing direct SQL inserts and bypassing all Django ORM model validation, there's no guarantee that the data will be in a valid state. (If you wanted to insert records via API or CSV and then modify the IDs retrospectively, you'd have to simultaneously change all the foreign keys which referenced that ID. Also not simple).

Resetting the sequence to 4000, and then importing records one by one in the right order, might just about work. It also means you don't have to reset the sequence afterwards.

In short: caveat emptor.