Add demonstration generated code for ordered maps in ygot #819
Conversation
| } | ||
|
|
||
| // Update updates a current policy statement, returning an error if the statement | ||
| // doesn't exist or if the key is unspecified. |
There was a problem hiding this comment.
i don't think Update and AppendNew would be that useful, what use cases did you have in mind for them.
I'd rather have GetOrAppend(key) *RoutingPolicyDefinition
There was a problem hiding this comment.
I added Update as a basic dictionary operation. I don't have a specific use case in mind. I think it's ok to remove it if we want to keep to specific use cases.
AppendNew was added because Scott mentioned the current New will be useful alongside Append. This would be the equivalent for ordered maps.
As for GetOrAppend, this was in the draft I proposed originally since it follows existing conventions with unordered maps. I received feedback that this might be confusing because they want to know whether it was a Get or Append, since with ordered maps each element in general (e.g. BGP policies) cares about what other elements already exist, whereas in unordered maps each element often does not care about the existence of other elements (e.g. interfaces). So splitting it into Get and AppendNew helps the user write code that's less ambiguous. The stakeholders mentioned New and Append as the primary functionalities that they would use.
There was a problem hiding this comment.
I'll try to get a code review from the users.
There was a problem hiding this comment.
So I got feedback that Append is probably all they will need. For AppendNew I think given this API exists in the existing API method set, that it does not subtract value to have. I've removed Update though since I agree it might be a stretch for people to use it. PTAL
There was a problem hiding this comment.
here's my thoughts.
- GetOrCreate is by far the most commonly used function (at least in featureprofiles). Because it doesn't return an error, it is really convenient to use.
- Append: is very rarely used, though it's a still valuable and should exist
- AppendNew: I don't see this in the existing API set, and personally don't see when i'd use it.
however, i'm fine with the API as is.
There was a problem hiding this comment.
I agree with 1&2 from a current-API perspective, the current PR reflects iteration after feedback. Ordered-maps are different than unordered-maps and IMO this method set has greater usability than simply copying what the existing unordered-map API does.
For 3 AppendNew corresponds to New for unordered maps.
| type RoutingPolicy_PolicyDefinition_Statement_Map struct { | ||
| // TODO: Add a mutex here and add race tests after implementing | ||
| // ygot.Equal and evaluating the thread-safety of ygot. | ||
| //mu sync.RWmutex |
There was a problem hiding this comment.
You should add locking code now around any fields that could be modified while other code is reading/modifying them.
There was a problem hiding this comment.
Sure, I can add now.
There was a problem hiding this comment.
Actually I will hold off pending our discussion below, I'm still not convinced it's the right time to add this since the rest of ygot doesn't deal with thread-safety. If we do want thread-safety I think we would want another suite of tests. I also think this can be added in a separate PR.
|
|
||
| // Keys returns a copy of the list's keys. | ||
| func (o *RoutingPolicy_PolicyDefinition_Statement_Map) Keys() []string { | ||
| return append([]string{}, o.keys...) |
There was a problem hiding this comment.
All of these functions should grab a mutex for the duration of their access to the fields in the struct.
There was a problem hiding this comment.
I can add it. Although the reason why I don't think it's important to add this now is because ygot-generated code is not currently thread-safe. There are instances of slice types, and slices by themselves are not thread-safe -- they would have to be encapsulated just like this type for them to be so. The other pointer types are technically ok because they're benign data races, and perhaps in Go these are truly benign, although I'm not 100% sure.
| } | ||
|
|
||
| // Len returns a size of RoutingPolicy_PolicyDefinition_Statement_Map | ||
| func (o *RoutingPolicy_PolicyDefinition_Statement_Map) Len() int { |
There was a problem hiding this comment.
Should there be the typical race condition warning that the return value may become incorrect immediately after being returned? Is this more a desire to know if it is empty or not?
There was a problem hiding this comment.
Sigh, I think similar to the above, ygot was not designed to be thread-safe, and so for the current map and slice types users would be calling len() just like this function does. IMO it doesn't seem very useful to the user if one very-rare type in the GoStruct is thread-safe while everything else needs a lock anyways. That's why I'm not sure about the value of making this thread-safe at the current time.
Once this is approved development for code generation can begin.