Fork me on GitHub
#pathom
<
2019-06-18
>
codonnell01:06:12

@wilkerlucio Home now; this is what my oir and indents indexes look like. (I abbreviated "little-gift-list.type" as "gql" in previous snippets for brevity.)

codonnell01:06:11

little-gift-list.type/gift-list is not an ident root query; it does filtering/sorting/pagination on gift list entities. little-gift-list.type/gift-list-by-pk is an ident root query; it takes id as its only param and selects that gift list. little-gift-list.type/gift-list-aggregate includes some aggregation capabilities: max, average, etc. on query results.

wilkerlucio01:06:06

@codonnell my suspect is that the ident map is not mapping with the graphql for some reason

wilkerlucio01:06:18

it has to find it there to work (so it can pull details in)

wilkerlucio01:06:30

can you try doing without any munging and see how it goes?

codonnell01:06:50

Sure, I'll give that a try.

codonnell01:06:52

Alright, I removed the mung/demung config, and it works!

codonnell01:06:51

And the oir index is properly populated with values

codonnell01:06:06

I'd prefer to keep the munging; would you be interested in a PR that fixes the indexes with munging config in place?

maxt07:06:24

I'm trying to use the placeholders, but if I have two, it seems like only one is getting called. It that expected somehow, or am I misunderstanding something? My query looks like this:

[{:company
  [:company/uuid
   {:>/customers
    [:company/uuid
     :company/customers]}
   {:>/employees
    [:company/uuid
     :company/employees]}]}]

maxt08:06:01

Hm, when I make really simple resolvers it does seem to work, so it must be something else.

maxt08:06:07

I found the problem. I had one resolver that returns different results depending on (::p/parent-query env) but pathom don't want to call that resolver twice. Creating separate resolvers seems to solve the problem I had.

👍 4
wilkerlucio12:06:33

@maxt resolvers are cached by input+params, so if its only an env change it will be cached, having separated resolvers is a good option, another you can do is set ::pc/cache? false on the resolver to remove caching, I would recommend keep caching unless its a very cheap operation

souenzzo12:06:56

::pc/cache? is a global or resolver option?

kszabo12:06:09

resolver

👍 4
maxt13:06:51

@wilkerlucio Ok, thanks for clearing that up. I think some of my confusion might come from that I'm using datomic, and it fields weird to disassemble the pull query and define separate resolvers when I can just send the pull-expression directly to datomic. (with validation ofcourse)

maxt13:06:46

I haven't really seen any examples of using datomic and pathom togehter.

wilkerlucio13:06:04

@maxt yeah, with datomic it feels tempting to just delegate everything out (having one resolver to rule then all), but I think its better if you separated those in your mind, what pathom is providing is an access to some keys, it just happens that a lot of time those will just match, and a pull query can get it all. so what I see people doing is create one resolver for each "entity" (in a very loose entity sense), exporting all the scalar values, and one separated for each relationship, since in datomic its quite cheap to pull all these attributes its fine. one for each relationship to reduce traversing. I guess this is a good start point, and later you can tune it up if you see performance opportunities. makes sense?

maxt14:06:15

@wilkerlucio Yes, I think it does make sense. That's kind of where it's leaning already. Thank you for confirming that it's tempting to delgate everything. I guess one way to think of it is that pathom is the query validation (aka authoirzation) layer.

eoliphant14:06:31

+1 Pathom + Datomic is a match made in heaven, but it’s not 1 to 1. but we’ve ended up with a web of resolvers, some datomic ‘helper’ funcs that take advantage of the similarities and paper over the differences (handling ‘enums’, etc). It’s nice because you can end up following clean arch, etc principles, but with far less work in terms of translation.

👍 12