Open
Conversation
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
tmt saves its state info - step data, test data, guest data, etc. - in
YAML format, plent yof `*.yaml` files in a workdir. It's fine, it's
readable by both machines and humans, it works.
It turns out YAML is not necessarily the best format out there, as YAML
can be costly to generate when dealing with large structures and large
collections.
Two things happen in this PR:
* To allow some experimentation, `TMT_STATE_FORMAT` environment
variable tells tmt which format to use when storing its data. As of
now, only `yaml` is supported.
* "to/from JSON" helpers are refactored to align with recent changes to
"to/from YAML" helpers, to provide similar function names,
annotations and so on, and they are made available for selection via
`TMT_STATE_FORMAT`, making JSON the second supported format for tmt
state files.
Moar formats, moar fun!
A set of simple helpers, `to_state` and `from_state` is defined, based
on the aforementioned envvar, and patch changes all places where tmt
stores state on disk to use them instead of `{to,from}_yaml`.
`Common.{read,write}_state()` will help with that, instead of
`Common.{read,write}()` methods.
Now we can play with different format, and even if we learn the format
is not the culprit of ineffective storage of large collections of
results, we will have nice and tidy internal API to work with.
happz
force-pushed
the
to-state-helpers
branch
from
d466104 to
cb39366
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
tmt saves its state info - step data, test data, guest data, etc. - in YAML format, plent yof
*.yamlfiles in a workdir. It's fine, it's readable by both machines and humans, it works.It turns out YAML is not necessarily the best format out there, as YAML can be costly to generate when dealing with large structures and large collections.
Two things happen in this PR:
TMT_STATE_FORMATenvironment variable tells tmt which format to use when storing its data. As of now, onlyyamlis supported.TMT_STATE_FORMAT, making JSON the second supported format for tmt state files.Moar formats, moar fun!
A set of simple helpers,
to_stateandfrom_stateis defined, based on the aforementioned envvar, and patch changes all places where tmt stores state on disk to use them instead of{to,from}_yaml.Common.{read,write}_state()will help with that, instead ofCommon.{read,write}()methods.Now we can play with different format, and even if we learn the format is not the culprit of ineffective storage of large collections of results, we will have nice and tidy internal API to work with.
Pull Request Checklist