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)

let me double check if I didn't add that

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

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))))

but of course this has a lot of pitfalls

I expected it to be implemented here: https://github.com/wilkerlucio/pathom/blob/master/src/com/wsscode/pathom/core.cljc#L969

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

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

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

sure

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

or would you decide that later

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

without breakage when I upgrade and remove my solution

https://github.com/wilkerlucio/pathom/issues/118

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

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

sure, sounds good

thanks for being so responsive! 🍷

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

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?

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

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.

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

Access the resolver?

access the db in your case

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.

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

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

The generator is not very fast 😬

you can also see it here: https://edn-query-language.org/eql/1.0.0/clojure-specs.html

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

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

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

this was a way I found to make then very customizable

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)

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

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

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

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

ends up looking something like this:

I absolutely agree. Just suggesting a better default 🙂

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

🙂

the default will do a max of 5 depth levels

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

there just too many moving pieces

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)

run this fn with your indexes and you get it: https://github.com/wilkerlucio/pathom/blob/master/src/com/wsscode/pathom/connect/gen.cljc#L80

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