Write a created object configuration under a DEFAULT header - #1104
Merged
Conversation
"om test1 create --kw fs#1.type=flag --kw nodes=*" wrote the nodes keyword, and the id that goes with it, past the "[fs#1]" line. The object read back had no nodes and no id, and an fs#1 resource that had both. The same create with the keywords in the other order was correct, so the object a user got depended on the order they typed. The default section of a parsed document has no header node: the keys before the first section header are its keys, and a document that had no header is written back without one it never had. A key added to it had no node to be inserted after, and insertNodeAfterSection appended it to the end of the document, which is inside the last section. It appended correctly while the default section was still the only one, which is why the first order worked. A key of a headerless default section now heads the document, where it belongs. Configuration files written before this fix have no DEFAULT header either, so this is what "om <obj> set --kw nodes=..." on one of them needed too. The create codepaths, local and api-side, then materialize the header, and the sections a document is built with are separated by a blank line: a new object configuration looks like the v2 one it replaces, whatever the keyword order. Only an encoded section header is separated, and only a document with no default section header materializes one, so a configuration nobody reformatted is still written back byte for byte: "om config edit" with no edit leaves the file untouched, and a configuration imported with "--config" keeps the layout it was written in.
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.
"om test1 create --kw fs#1.type=flag --kw nodes=*" wrote the nodes keyword, and the id that goes with it, past the "[fs#1]" line. The object read back had no nodes and no id, and an fs#1 resource that had both. The same create with the keywords in the other order was correct, so the object a user got depended on the order they typed.
The default section of a parsed document has no header node: the keys before the first section header are its keys, and a document that had no header is written back without one it never had. A key added to it had no node to be inserted after, and insertNodeAfterSection appended it to the end of the document, which is inside the last section. It appended correctly while the default section was still the only one, which is why the first order worked.
A key of a headerless default section now heads the document, where it belongs. Configuration files written before this fix have no DEFAULT header either, so this is what "om set --kw nodes=..." on one of them needed too.
The create codepaths, local and api-side, then materialize the header, and the sections a document is built with are separated by a blank line: a new object configuration looks like the v2 one it replaces, whatever the keyword order.
Only an encoded section header is separated, and only a document with no default section header materializes one, so a configuration nobody reformatted is still written back byte for byte: "om config edit" with no edit leaves the file untouched, and a configuration imported with "--config" keeps the layout it was written in.