asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <>
Subject Re: The "real" ADM format
Date Wed, 08 Jun 2016 03:53:26 GMT
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.

aka Chris Hillery
On Jun 7, 2016 8:17 PM, "Ian Maxon" <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message