Clojurians Log v2

Hi all. A style question really. Is it reasonable to use defmutation to define an action that doesn’t really change state? I’d like to leverage pathom as the principal API across multiple backend services including operations such as search or login. I guess the latter might change state - eg audit trail - but search is idempotent. What’s the ‘best’ way?

yes, no problems using mutations like that, I see mutations as “commands”. while attributes are about getting some piece of data, mutations are about telling something to happen, its ok if they dont change state

Thank you Wilker!

altough search is the most gray area here, because its asking for data more than asking a command, but Im not the police, do whatever works for you :)

Hi 👋 A small question about attribute nesting. I came across this today, trying out pathom3.

(pco/defresolver foo [{input :input}]
    {:foo
     {:msg (str "Foo: Hello, " input)}})

   (pco/defresolver bar [] ;; no dependencies
     {:bar "This is bar"})

   (def env
     (pci/register [foo bar]))

   (p.eql/process env
                  {:input "World"}
                  [{:foo [:bar]}])

   ;; => {:foo {:bar "This is bar"}}
   
   ;; BUT with...

   (pco/defresolver bar [{foo :foo}] ;; depends on :foo
     {:bar "This is bar"})

   (p.eql/process env
                  {:input "Hello"}
                  [{:foo [:bar]}])
   ;; => {:foo {}}

I was trying to “further resolve” attribute by pulling from db (datomic). Additional data would be nested in what I already have like :bar in the example. But this doesn’t seem to work when :bar depends on the parent key (:foo here). Nesting works fine when :bar has no dependencies. Is there a way around this or maybe there are good reasons for this and it’s the intended behaviour ;)?

I'm a heavy user of pathom3 and I've run into a number of bugs related to @wilkerlucio latest post https://blog.wsscode.com/pathom-updates-09/ . I don't know but I suspect you are running into a planner bug. fwiw, the following resolver will produce a result

(pco/defresolver foo-bar [{_ :input}]
  {:foo {:bar "This is bar"}})

@prnc ^^

Pathom is doing the expected stuff in this example

on the second case, where :bar depends on :foo, at that context you asked :bar, there is no :foo

Pathom looks at each entity level

the parent entity has :foo, but that’s not where you are asking for it

(p.eql/process env
                  {:input "Hello"}
                  [:foo :bar])

in this case ☝️ they are siblings, so :bar can see :foo, and that’s valid

but you can’t ask for parent attributes

yes, it is intended behavior

dependencies are across the same entity, and with Pathom 3 there is support for nested requires (goes down), but never going up (looking at parent)

for Pathom, each map is an indepent entity, if we pulled data from all parents would be just crazy 😛

if a parent information is intended to be used on the children, the resolver that provides the children must pass it forward

hey @markaddleman, curious, did you tried upgrading to the version after the post? did you still see these kind of bugs after?

(and to clarify, in the case of prnc, its not a bug)

Haha, fair enough! Need to get my intuition around how things work in pathom a little stronger. Initially I was thinking it’s similar in philosophy to spec/rdf w/ global, “strongly namespaced” attributes

…and then resolvers sitting between them, i.e. edges: I have A and want B

Funny you should bring that up. I just tried upgrading to the latest commit and ran into some problems. I was just about to ask you if the latest commit contained fixes to the shared attribute problem that you describe in your post 🙂

In short, I have an attribute that is used by a couple of resolvers that share a parent child relationship. These parent resolver is probably three levels deep in the larger planning tree.

If I remove the common attribute from the input of one of the resolvers, the plan is generated. However, if the attribute is in the input of both resolvers, no plan in generated

I don't have a good way of creating a small reproducible case

I also did one fix yesterday related to nested queries

with the new planner I expect to have none (or very few) bugs related to flat queries

but I still need to get the generators to make nested cases, them the confidence on those can increase as well

gotcha. For now, I am working with an older commit and several of my resolvers must perform p.eql/process explicitly rather than depend on inputs. It's a good enough approach for my needs 🙂

it is, one thing to help is remember to isolate the context in one entity, the parent example, is like this: A has :foo, which is an entity (lets call it B), now I navigate to entity B and ask :bar from it, now why I can’t find :foo in B?

If it would be helpful, I'd be happy to screenshare my code so you can see firsthand the problem with the latest commit. Maybe do that after you get the generators to make nested cases and you have a chance to work out those bugs.

any time you navigate to a new map, is like navigating to a new entity in the graph

makes sense?

Thanks @wilkerlucio — just for context of this, to make it slightly more practical: I was wondering how one could replicate datomic pull behaviour in which e.g. in pathom say I get {:media/uri {:db/id 2344534545}} from some resolver and the request to pathom is [{:media/uri [:uri/host]}] and :uri/host could be resolved based on that :db/id if requested like above. So in my mind the resolver returning {:uri/host} would depend on the parent of {:media/uri ,,, } , no?

no, :uri/host should depend on :db/id

so using a :db/id you fetch the entity and read the :uri/host from it

I see, that makes a lot of sense.

Thanks so much! Now let me experiment some more and get a better understanding before I tire you too much with all that 😜

no worries, have fun 🙂