Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to ignore read-only fields (config: false) for ytypes.Unmarshal #757

Open
rimpsh opened this issue Dec 22, 2022 · 1 comment
Open

Comments

@rimpsh
Copy link

rimpsh commented Dec 22, 2022

Hi,
I'm a student and I'm currently experimenting with ygot in a university project.
Within this scenario I work with a generated GoStruct that also includes read-only fields. For my use case, an option to ignore read-only fields while unmarshalling into a GoStruct (e.g., when preparing a gNMI.SetRequest) would be really useful.

I'm aware of the excludeState option for the generator but since I sometimes need read-only fields (e.g., unmarshalling data from a gnmi.GetResponse) and in some cases I do not, this option does not really fit.

One possible solution could be to extend the ytypes.Unmarshal function which allows to ignore read-only fields while unmarshalling. For example like:

type IgnoreReadOnlyFields struct{}

// IsUnmarshalOpt marks IgnoreReadOnlyFields as a valid UnmarshalOpt.
func (*IgnoreReadOnlyFields) IsUnmarshalOpt() {}

I've tested this in a fork and if this is something that ygot would benefit from, then I would also try to add this to the project.

@wenovus
Copy link
Collaborator

wenovus commented Jan 17, 2023

Hi @rimpsh Thanks for sharing us your fix.

There is currently a workaround for the problem you described, which is to call the function ygot.PruneConfigFalse. I will admit this is not very discoverable by autocomplete tools, and is an issue that we should take a look at.

I think using the workaround might be easier from a user perspective (once we have the discoverability issue fixed).

However, if your change is pretty simple it might be worth the maintenance effort. I'd say feel free to open a PR and reference this issue so we can at least keep your work in the record.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants