amzn
Keeping order of insertion
It would be very useful to have an option to keep the order of insertion of the keys. This option would be diferent from sort_keysor item_sort_keys where the user needs to specify how the sorting will be done.
I think this has been also requested for simplejson, but it was discarded because it wouldn't be valid JSON as JSON is unordered.
Would such a feature be desirable in simpleion?
Similar to JSON objects, Ion structs are unordered, so introducing the notion of maintaining insertion order is surprising--why not use a list? It would be interesting to understand your use case better....
It's something we'd need to consider wrt consistency across all Ion parsers, and would I suspect require a change to the specification.
I'm developing some scripts that append / modify data in ION documents. These changes are code-reviewed and it's mandatory to focus strictly on the data because changes in formatting (like changing the order of the fields) make the diff impossible to read. Also, the order of the fields is not random and needs to follow some conventions.
I understand that this might be against the ION specification, so I might need to look for an alternative solution (a fork maybe?).
Thank you for providing some additional info. Forking sounds a bit heavy-handed here, plus it incurs additional maintenance costs. Sounds like if you had a dumps() alternative that allowed you to apply your field-ordering conventions prior to diffing, you'd be all set; I suspect there are approaches to making that happen that don't involve forking the library.
I've implemented the item_sort_key functionality (pull request waiting to be reviewed here: https://github.com/amzn/ion-python/pull/84) . This works for the 'conventions' part, but that's only a small part of the problem.
I'd like to be able to perform changes over existing ION files without modifying the original order of the fields; this not only involves modifying the dumps, as it requires adding another kind of IonPyDict that preserves the order in which the documents are read. It should be completely up to the client to use this dictionary or the original one.
We were ok this feature as long as it's optional and the client has to opt in to use it. We'd be happy to review a PR for it
