Ah, the other thing I forgot to mention is that I didn't include interval types, because I'm not sure about their current status. There was some discussion on the list in January (subject "Round Tripping ADM Interval Data") but I'm not sure where it ended up as far as the form of the constructors, and whether that was AQL or ADM or both.
Ceej aka Chris Hillery On Tue, Jun 7, 2016 at 9:34 PM, Chris Hillery <[email protected]> wrote: > I started to create the current inventory of types, with the forms > accepted / produced by the ADM parser, AQL parser, and ADM serialization. > (I think we all agree that ADM parser and ADM serializer should be 100% > compatible.) Here it is: > > > https://docs.google.com/spreadsheets/d/1-11a9ETV1Bdh_bUm9_CszY4hEGJGbEBaVKUWrzeS-As/edit?usp=sharing > > I know this is not comprehensive (for instance, I'm pretty sure that a > naked integer will be parsed by both ADM and AQL as an int64, so that form > should be listed as an alternative) and I haven't verified that the AQL > parser forms in particular are accurate, but I think it's close. I've set > it so anyone can edit that document, so please fill in the gaps if you know > of any. > > We should also fill in the exact accepted forms for the various derived > types like the datetime, spatial, hex, and UUID types - eg., the valid > forms of the double-quoted string in the duration() constructor is as > specified by XML schema, and so on. > > Ceej > aka Chris Hillery > > On Tue, Jun 7, 2016 at 8:53 PM, Chris Hillery <[email protected]> > wrote: > >> 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 >>> >> >
