On our mailing list, there is quite often the question whether attribute names in objects returned from AQL queries can be made dynamic.
Here’s a (non-working) example query for this:
The intention in the above query obviously is to use the dynamic value from
an attribute name in the result object and not to have an attribute named
feature is probably in the top 20 of the most-often wished features.
1 2 3 4
Why not allow arbitrary expression left of the colon? The reason is simple: this would cause ambiguity and probably have side-effects. For an example, have a look at the following query:
1 2 3
type attribute name inside the object definition is interpreted as a string literal
as it currently is an AQL (and always was), then the resulting attribute name is just
type attribute name would now be intepreted as an expression, it would get the value
that was assigned to the variable
type by the
LET statement. Removing the
LET from the
query would change the attribute name in the result back to the string literal
The ambiguity could be solved by telling the parser what to do in such cases. While technically
this could be working, I think it may have too many unintended side-effects. I already mentioned
that introducing a
LET statement into the query would change the attribute name in the result.
The same could also happen if a collection named
type was added to the query. And it would
break compatibility with existing queries.
for ES6 that suggests enclosing attribute name expressions in
To me, this looks like a good solution for the problem. It’s two bytes more when keying in queries, but the syntax is easy and explicit. There are no ambiguities.
I prototyped this solution for AQL, so I could write:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
I ran a few queries with this, and they seemed to work.
However, I haven’t
committed the feature yet. There might still be cases in which it doesn’t work. Tests
for the feature are also still missing. I hope I can finalize the implementation soon
so it becomes available in some release.
UPDATE: tests have been added, and the feature has been committed in devel. It is included in ArangoDB since version 2.5.
Everyone is welcome to try it out already!