Hi all Comparing storing a set of DHCP options as extra json info in nic details with a new formal specification in sql, I would judge the formal approach as long-term preferred ? I understand everything can be modeled in json as well - i just want to understand better the arguments pro that approach, compared to the proposed extra table. Json has the drawback of higher error proneness (as less formal) and (slightly) reduced performance, as I see it. Also depending on the design, every network plugin would need to understand how to process the json info, again relating to my point of error-proneness.
thanks, Kris On 8 February 2017 at 16:49, Sergey Levitskiy <sergey.levits...@autodesk.com > wrote: > I personally like this option. This way you can obtain all DHCP options at > once very fast and manipulate them as you see fit in the respective module > - A second option could be that we store all the DHCP options in > *one* > key,value pair. > > As key we pick a specific value say; "extra_dhcp_options" and as > value: we > decode all the dhcp options (code + value) as json. This makes updating > DHCP options on a nic more complex. > > > >
