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

Optimize workspace builder resource dump format #411

Open
vaterlaus opened this issue Jan 10, 2024 · 1 comment
Open

Optimize workspace builder resource dump format #411

vaterlaus opened this issue Jan 10, 2024 · 1 comment
Assignees
Labels
bug Any bug enhancement New feature or request

Comments

@vaterlaus
Copy link
Contributor

Currently the resource dump contains a lot of extraneous content that doesn't actually add any information and could be stripped out to greatly reduce the size of the resource dump file. Examples are:

  • fields with null values
  • fields with empty dictionary/list values

Also, when I looked at current dumps after recent changes it seems like the resource dump is including YAML tags/references, which I thought I had removed, so I think there's some regression there that I need to look into.

@vaterlaus vaterlaus added bug Any bug enhancement New feature or request labels Jan 10, 2024
@vaterlaus vaterlaus self-assigned this Jan 10, 2024
@vaterlaus
Copy link
Contributor Author

When the resource dump/load feature was added recently the esource dump format is now the YAML serialized form of the resource registry, which can then be deserialized to reconstruct the registry from the dump file. So the dump format now contains YAML tags/references, so that part of the description is no longer valid. It's still the case that it includes fields whose value is null or empty arrays/objects, which seems like they could be pruned from the dump to simplify and reduce the dump size without substantively changed the content. Although I'm a little worried that that could subtly affect the deserialized content when the dump file is reloaded, so we'd need to do some testing that it didn't affect the evaluation of the generation rules. Given that caveat I would deprioritize this ticket, especially because I think the existence of the empty content doesn't dramatically increase the size of the dump file and it's really only a developer-facing feature so it's ok if it's not super optimized/efficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Any bug enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant