jsnyder81
commented
5 months ago We discussed yesterday during the call the thought around using the floorplan vendor_id as an alternative to the name which can be used as a unique ID to match on. However, I don’t like having multiple keys to match on as it increases complexity of implementation I.E. match on name or match on ID and if both are present prefer ID. This assumes that vendors have a unique ID (which I’m sure they do). The logic for this is also difficult to implement in the schema and introduces a breaking change. which means we would look at it introducing it at the next major version.
When we first developed the model, the idea was a way to represent a single design. The scope of that design wasn’t determined, but most designs are specific to a building. However we did not develop the concept of the building (which is probably something we need to define).
If we defined a building we could match in both building and floor for a unique combination and that would likely be non-breaking. If you wanted to join today’s OI call, it will likely be a topic of discussion.
Today, with no concept of a building, and the requirement that floor name is unique within the scope of the payload, having something like
Hi Jake!
Please tell me when I get this wrong, but I understand that there is a unique name in the building/floorplan model.
If I have a campus with multiple buildings, there will be multiple floors called "basement" or "floor 1". Is the scope of that model always a single building? I suggest to add "campus support" by removing the uniqueness of the name string and adding unique identifier ids for the floor and the corresponding building.