Add eval to allow for custom inputs to queries

Would you be open to me adding an eval on the inputs to custom queries? It would make queries even more flexible.

Here are two examples of custom inputs I’d like to have. Right now, having access to those inputs requires adding new cases to resolve-input, i.e. a full code change. It’d be really cool if it could all just live in the users’ markdown files and be more dynamic!

There’s already an eval on result-transform, so I don’t think it’d affect the security model.

Yes, we’re open to adding an eval on the inputs to custom queries :slight_smile:
To make it really works, we might need to provide some bindings for sci, for example, the util/time-ms, because sci doesn’t have access to this function and runtime vars by default.

It might be tedious to bind each function in a namespace (for example, cljs-time.core), I just searched the issues and it seems that we can bind the whole namespace with ns-publics Binding/allowing a whole namespace? · Issue #158 · borkdude/sci · GitHub

Hmmm since it would require providing bindings for sci (something like the below, I presume), that still requires going into the source and actually adding the bindings each time.

{:bindings 
   {'time-ms util/time-ms
    'time-to-long tc/to-long
    'println println}}

This is slightly more flexible than having the pre-defined symbols like :today and :1d-after and that kind of thing, because then you can use them as functions rather than being stuck with whatever arguments the symbols happened to support, but only slightly more flexible.

Do you think it’s worth it to add the eval after all? I lean towards “no”, but I’m on the fence.

1 Like

Those bindings are mostly related to debugging (e.g, println, pprint) and date/time, right?
How about adding bindings for the debugging functions and several namespaces from cljs-time like this:

{:aliases '{t cljs-time.core}
 :namespaces {'cljs-time.core (ns-publics 'cljs-time.core)}}

This way, we don’t have to add every function ourselves, and still, it’s flexible enough.
Although, I haven’t tried the above code.

1 Like

That’s a good point, those would be really useful and add a ton of flexibility on their own. I’ll give that a swing!

1 Like