If it's possible, I think it would be least confusing if the serialized ADM format was identical to the corresponding data constructors in AQL. It should be a goal IMHO that you can cut-and-paste an ADM file into the query box in the web UI and the result would be the same as loading the .adm.
For more specifics, I think we need to write out for each data type what the current ADM and AQL formats are, and then pick a final answer for the type (which may possibly be different from either of the current forms, although I suspect not). That will he the spec, and we can update the two parsers (and all the test cases) accordingly. I started an email thread sometime last year about something similar; I think it was about JSON serialization, but it at least had the AQL side of this story for all simple types, I believe. Ceej aka Chris Hillery On Jun 7, 2016 8:17 PM, "Ian Maxon" <[email protected]> wrote: > Hi all, > After my experience with having to fix a rather large ADM file dump from a > query to make it load back into the system I was compelled to try my hand > at making that not happen again. The first thing I tried my hand at was > basically what I did to make the file loadable but inside the type > printers; just remove all of the 'i32' and so on suffixes, as well as > making decimals not formatted in scientific notation. This is pretty easy > to do as well, not a huge change code-wise (but obviously I'll have to fix > all of the tests). > > This got me to think though, which is the format that we actually want? The > current format that is output, or the format that we accept in the loader? > Since this is actually perhaps a language level change either way I figured > I should find consensus before spending more time on it. > > Thoughts/comments are appreciated. > > Thanks, > - Ian >
