Potential Hubs and Supernodes are not shown in MeshDB's map

[Andrew-Dickinson]

So whoops, in a similar vein to #402 we are unable to represent potential hubs and supernodes without assigning an NN. This is obviously bad, since we can't show the correct potential dots on the map for these sites

[Andrew-Dickinson]

Options:

1) Go back to parsing the word hub that we imported from the spreadsheet from the install notes in order to tell the map that this install is a potential hub. Upsides: easy and fast. Downsides: brittle and unpredictable (we really tried to avoid this for literally every other facet of map render)

2) Introduce a new field on install which allows us to select "node type" similar to how we do this with Nodes. Upsides: unambiguous. Downsides: duplicative of the field on node, going to be unused for active nodes

3) Assign NNs for potential hubs? Upsides: simple, few code changes. Downsides: inefficient use of NN allocations

4) Change the primary key for the node object to something other than NN, allowing potential Node objects without assigning an NN. Upsides: no data duplication. Downsides: APIs and URLs get very confusing

  4a) Assign potential hubs super high "fake" NNs like `100000xxxx`

5) Add an additional PotentialNode table or data structure to capture this concept somehow, similar to how we did with LOS. Delete PotentialNode objects at NN assignment. Upsides: no data duplication, unambiguous. Downsides: state-as-db-table sucks, more complex or limited schema (e.g. Links probably can't connect to PotentialNode objects without great pain) 6) The new table could instead be something like MapDisplayOverride or something (with a foreign key to a union of Node and Install, or gasp node number?), which is used by the map render logic to override whatever it was gonna do. Upsides: lets admins go crazy with map mods, simple and obvious non-duplicative data structure. Downsides: really doesn't scale beyond map render, very hard to maintain on the code side long term

[Andrew-Dickinson]

Perhaps we could do option 4, but keep all existing URL and API interfaces the same (this might be hella painful in the admin UI though IDK). Basically the only place the real pk would be used would be internal to the db, but the URLs would all reference the network number

[WillNilges]

After a phonecall, we had two thoughts:

• Add two fields to the Install: "Planned Hub" and "Planned Supernode" which will control the size and color of the dot
• Add a union field between name and NN, where the name field is for when you don't have an NN, but if you assign it, it gets clobbered.

But, the better thing to do would be to update our models so that we don't care about our PK. We turn it into a UUID (or some other industry standard ID) and then we gain a ton of freedom. @Andrew-Dickinson is going to try doing this.

The Admin UI can use the UUID (we don't care). There will be some work to do here to make the UI work properly after this. We will need to ensure that things like the NN is enforced.

We need to make sure that the URLs of the API still work.

We will also need to add an extra field to the serializers wherever we reference an install # or a NN.

[WillNilges]

https://pypi.org/project/shortuuid/