Fork me on GitHub
#pathom
<
2019-08-27
>
kszabo12:08:29

I might be missing something trivial, but in my ::p/process-error handler I can’t see the full tx in the env to report/log

wilkerlucio14:08:26

humm, erros go localized, so the AST will be at the location it failed, maybe that's a missing feature (having access to the root query)

wilkerlucio14:08:34

let me double check if I didn't add that

kszabo14:08:19

I checked with REBL and there was no such thing in the env, using quick-parser

kszabo14:08:45

I essentially circumvented it with this:

(defn parse-fn! [parser]
  (fn [env query]
    (-> (parser (assoc env ::p/tx query) query)
        (async-clj/<!!maybe)
        (async-clj/throw-err))))

kszabo14:08:02

but of course this has a lot of pitfalls

wilkerlucio14:08:27

it sets the parent query, but that changes on each path going down

wilkerlucio14:08:39

seems like a simple thing to add (you can also do it as a plugin)

wilkerlucio14:08:10

I think pathom doesn't provide that, but I'm willing to add, can you please open an issue for it?

👍 8
kszabo14:08:17

can I ask, will it be ::p/tx?

kszabo14:08:27

or would you decide that later

kszabo14:08:37

just so that I can assume in my code that it will be a some key

kszabo14:08:49

without breakage when I upgrade and remove my solution

wilkerlucio16:08:39

@U08E8UGF7 I think ::p/root-query will be the name, makes sense?

wilkerlucio16:08:04

so it aligns with current ones ::p/query and ::p/parent-query

kszabo16:08:14

sure, sounds good

kszabo16:08:37

thanks for being so responsive! 🍷

🙏 4
kenny19:08:02

Can you require that a particular key exists in the env for a resolver to get called?

wilkerlucio19:08:34

no, that's inputs job, can you tell more about the use case?

wilkerlucio19:08:28

one simple way to handle it, is making a resolver that pulls your key from env to some output, and them depend on that, makes sense?

wilkerlucio19:08:43

(if the key is not present on env, return a blank map, so pathom understands thats unreachable)

kenny19:08:10

Sure. We have a Ring application that has an eql endpoint. Certain requests are authorized to access different dbs. When a query tries to pull data from a db that is does not have access to, it should return not-found. That exactly what I ended up doing 🙂 Seems like an acceptable approach.

wilkerlucio19:08:00

the only downside I see he is that you enable users to access that directly (and you may not want that), to go around that you can have a plugin that removes this from the output

kenny19:08:34

Access the resolver?

wilkerlucio19:08:54

access the db in your case

kenny19:08:45

In this case I wrapped the resolver fn in a when so the whole thing is skipped. I imagine more complex use cases may require something like what you just described.

wilkerlucio19:08:08

cool, yeah, you don't have to acutally put the value there, just a signal its available 🙂

kenny19:08:53

Is there a spec for an EQL query?

kenny19:08:07

Ah, part of edn-query-language: :edn-query-language.core/query

kenny19:08:42

The generator is not very fast 😬

wilkerlucio19:08:15

I recommend you avoid using the "raw generator", that will generate too much randomness, usually is not what you want

wilkerlucio19:08:38

but I designed them in a way that you can "cherry pick" how the generation works, you can find info for it here: https://edn-query-language.org/eql/1.0.0/library.html#_generation

kenny19:08:09

Oh I see. They have a little make-gen helper. Why didn't they make that the default gen for the specs?

wilkerlucio19:08:37

this was a way I found to make then very customizable

wilkerlucio19:08:18

please check the docs first, the way they are done allow you to customize every detail on how queries are generted, since each user may have different cases (in my own usages I have several different configurations, depending on what I want to test)

kenny19:08:18

It seems fair to override the default generator for the specs so it at least generates in a timely manner.

kenny19:08:45

(gen/generate (s/gen ::eql/query)) will hang the repl after a couple runs.

wilkerlucio19:08:30

you can reduce the :size if you like to avoid that

wilkerlucio19:08:46

but I highly recommend you make a custom setup, its pretty fun, and gets more precisely what you need

wilkerlucio19:08:08

ends up looking something like this:

kenny19:08:09

I absolutely agree. Just suggesting a better default 🙂

wilkerlucio19:08:10

(gen/sample (eql/make-gen {::eql/gen-property ; 
                       (fn [_] (gen/elements [:id :name :title :foo :bar]))}
              ::eql/gen-query) 

wilkerlucio19:08:36

the default will do a max of 5 depth levels

wilkerlucio19:08:48

I don't remember exactly makes that hangs on the default

wilkerlucio19:08:56

there just too many moving pieces

wilkerlucio19:08:27

since we are talking generators, another cool feature you may want to look at is the connect generators, using that you can limit the query generation to your own index (so it only generates things your parser can resolve)

kenny19:08:00

Ooo, very cool. That's exactly what my end goal was!

🙂 4