Closed ramukima closed 8 years ago
Should the event be raised only after 'the change in model is validated against the schema' ?
To be honest, I wasn't really sure what the behavior for missing leafref should be. Because it is a relational dependency, it may be valid at the time it's being set but it CAN also become invalid if the data it's pointing at changes. So I opted to compute it at the Getter side instead of the Setter side. Which basically means that it currently accepts an invalid/missing leafref while you're setting it (since it may become valid at a future time when the referencing leaf can be resolved).
What I can do is to have it trigger an error - but still accept the data? Not too sure yet on the best approach for this...
The missing leafref is reported perfectly fine as seen above. I am not sure whether an 'CU' event must be raised on such things. Every subscription will then need to parse such errors on every event raised and that too for every field in the schema, which is not so good.
How does the system reject an invalid model when I do not pass any value for 'mandatory true' attributes ? Does that as well raise an event so that the model subscriber receives it?
Well, the CU events are raised because the input configuration was not rejected during Setter (despite the fact that missing leafref does make that configuration invalid). Basically we are implicitly treating it as a pseudo-valid configuration. I can also consider having it enforce during Setter so the data itself is rejected?
Except for the leafref case, all other constraint validations take effect during Setter - which means that an error will be thrown and no CUD events will be triggered.
Latest yang-js handles leafref resolution during Setter and will reject invalid value appropriately and not raise any CU events. Closing issue.
Model (alongside example/petstore.yang)
Create a foo:foo with wrong leafref value:
Petstore Server Log