Clojurians Log v2
pathom
I was wondering about this too, is calling a parser from within a mutation the correct approach for e.g. resolving some permission keywords that need to be taken into account? Or is there a better approach to resolve some contextual information during a mutation?
Is it possible to use back navigation in Pathom? (I’m using https://github.com/wilkerlucio/pathom-datomic). I.e.,
[{[:realm.schema/name :u.fluent/task]
[{:realm.node/_schema
[:realm/id
{:realm.node/root [:realm/id]}]}]}]Do I need to install realm.node/_schema manually for it to be recognized perhaps?
Figured as much @wilkerlucio, creating a manual parser works quite well, so it’d be great to have them generated. We’ll have a look at it and see if we can’t contribute something.
Or do we need to create manual resolvers for this kind of thing? Would be pretty awesome if the pathom-datomic plugin could just pass that through…
@thomasmoerman Perhaps your use case is more specific but in our mutations we'll typically return a map that has, at least, a /id attribute that a pathom resolver takes as an input. Pathom will then resolve any additional keys through the regular facilities.
no, back references are currently unsupported, if you like to add this I'll take a PR, what needs to change is to also generate the back link properties in the index: https://github.com/wilkerlucio/pathom-datomic/blob/f8a7d25e39cb3be13362eb8016402610f85f8517/test/com/wsscode/pathom/connect/datomic_test.clj#L770-L816
1👍My case is different: the idea is to call the parser to use the existing resolvers to resolve additional (e.g. permission) info that might prevent the mutation from executing. So it's not a mutation join using an /id return value, as you mention.
@wilkerlucio thanks for the info! let’s get to work then I guess @henrik 🌟 🚀
Could you alter the query prior to calling the parser?