You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to how we make variables available in lateral subqueries via over ... with <var>=<expr>, it seems users might benefit from being able to do from eval (...) with <var>=<expr>.
Details
At the time this issue is being opened, super is at commit 87ab6b7.
Consider the following query, which is a simplification of something like the example query currently in the super repo README.
$ super -version
Version: v1.18.0-160-g87ab6b72
$ echo '{user:"mccanne"} {user:"philrz"}' |
super -c 'from eval(f"https://api.github.com/users/{user}") | yield {user:user,created_at:time(created_at)}' -
{user:error("missing"),created_at:2012-08-07T18:52:36Z}
{user:error("missing"),created_at:2013-11-13T23:32:04Z}
As a naive user, I assumed that the user values upstream of my from could still be available post-from, but instead I've got only the new dataflow resulting from the from eval(...).
To get around this, I could use an approach like the one in the super repo README of using fork to split off the original dataflow and then later using join to somehow combine it back with the data that came out of the from eval(...). However, fork and join are more advanced language features, so that got me to thinking that users might appreciate a more direct way to handle this.
Following existing patterns in the language, the variables in over ... with ... came to mind, e.g., we might offer something like:
$ echo '{user:"mccanne"} {user:"philrz"}' |
super -c 'from eval(f"https://api.github.com/users/{user}") with orig_user=user | yield {user:orig_user,created_at:time(created_at)}' -
{user:"mccanne",created_at:2012-08-07T18:52:36Z}
{user:"philrz",created_at:2013-11-13T23:32:04Z}
The text was updated successfully, but these errors were encountered:
tl;dr
Similar to how we make variables available in lateral subqueries via
over ... with <var>=<expr>
, it seems users might benefit from being able to dofrom eval (...) with <var>=<expr>
.Details
At the time this issue is being opened, super is at commit 87ab6b7.
Consider the following query, which is a simplification of something like the example query currently in the super repo README.
As a naive user, I assumed that the
user
values upstream of myfrom
could still be available post-from
, but instead I've got only the new dataflow resulting from thefrom eval(...)
.To get around this, I could use an approach like the one in the super repo README of using
fork
to split off the original dataflow and then later usingjoin
to somehow combine it back with the data that came out of thefrom eval(...)
. However,fork
andjoin
are more advanced language features, so that got me to thinking that users might appreciate a more direct way to handle this.Following existing patterns in the language, the variables in
over ... with ...
came to mind, e.g., we might offer something like:The text was updated successfully, but these errors were encountered: