Add query/reference as a first-class VRL type.

[fuchsnj]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Use Cases

Today the syntax for "reading a value from an object", and "a query path referencing a field of an object" are identical.

Examples

query an object

. = {"foo": {"bar": 3}}
x = .foo.bar
# x is 3

delete a field

. = {"foo": {"bar": 3}}

# the function arg is treated as a "query". The value 3 is not passed into the function.
del(.foo.bar)

Having a distinct syntax for creating references vs accessing a field could allow more elegant code and reduce confusion here.
As an example, a vector user attempted to delete multiple fields in an object by using the following code (which doesn't work):

fields = [".source_type", ".kubernetes.pod_ip"]
for_each(fields) -> |_index, value| {
  del(value)
}

fields here just contains an array of strings, which fails to compile since del expects "queries". If fields was switched to
fields = [.source_type, .kubernetes.pod_ip], then it would just contain an array of the values that the query paths point to.

I am proposing that additional syntax is added to create "references", which just point to specific fields/indices of objects/arrays.
This is just a standard query path with & appended. For example, a = &.foo.bar would mean that the local variable a is a reference to .foo.bar. The above invalid example could be re-written with these changes so it would work as expected.

fields = [&.source_type, &.kubernetes.pod_ip]
for_each(fields) -> |_index, value| {
  del(value)
}

Note that this would require some additional work before it could be it could be implemented:

• Allow VRL to have additional Value types not in Vector #26

Version

0.24.0

[ayZagen]

are there any plans for this to happen? our vrl functions became hard to maintain as we play around json a lot. maybe title should be changed to receive more attention as no one would search it like that.

[jszwedko]

are there any plans for this to happen? our vrl functions became hard to maintain as we play around json a lot. maybe title should be changed to receive more attention as no one would search it like that.

👍 what keywords do you think would help people discover it?

[ayZagen]

After re-reading the issue description and why I have commented that, I realized this issue is just describing a new type for query path "as the title describes" 😅

The feature we need is Allow using strings as json paths which is related this issue. That's why I made that comment.

Sorry for that, as creating a new issue makes more sense.