flux icon indicating copy to clipboard operation
flux copied to clipboard

SPEC: object types should be renamed to record types and be ordered

Open adamperlin opened this issue 6 years ago • 0 comments

From ifql created by jsternberg : influxdata/ifql#345

This covers a few different sections of the spec. In the data model section, a record is listed as a "tuple of values" and a table is listed as a "set of records with a common set of columns and a partition key".

While the table definition is correct, I don't think a record is necessarily as simple as just a tuple. Most of the functions take a record as an argument and the record that is passed in is a set of key/value pairs for that single entry. While those keys are tied to the columns from the table, I think a record would be more accurately described as a tuple of key/value pairs. I think it would also make some other parts of the spec easier to follow and more useful.

Object literals could then be described as record literals since that's what they are. When I have the map function, I am taking in a record as an argument and returning a new record (the optimizer may feel free to mutate the inserted record if that record isn't being used elsewhere though). That way, this makes sense:

map(fn: (r) => {val1: r._value * 2, val2: r._value * 3})

I also believe records should be ordered (not sorted). Columns themselves are ordered and this will make it much easier to develop the transpiler since the transpiler can ensure that the types are mapped in the correct order so the output gets returned correctly. Otherwise, the return value of the above example is indeterminate since who knows which column will be first. Will val2 be the first column or will val1?

Allowing the tables to be ordered also makes it easier to implement something like left_join. The table that is left most is the one that gets joined to. It seems to make more sense to me in a language where ordering does matter.

adamperlin avatar Jul 03 '18 20:07 adamperlin