Fork me on GitHub

hi, i’m trying to figure something out. I’m using Pathom with datomic. So, when I ask the parser to do something I’m passing in {:conn conn :db db} this generally gives me what I want. queries across resolvers have a ‘stable’ db, and mutations just do their thing. However, I have a problem when I’m doing mutation joins. Because, of course here [{(add-foo ...) [:foo/a :foo/b] I need my foo-by-id resolver to get an updated db in its env. Any suggestions?


You could return the data structure you need within the mutation


(instead of having another resolver do that)


well the thing is, it’s not really part of the return value. the db ‘more rightly’ part of the env. and say my foo-by-id resolver shouldn’t care if part of a join, etc. BUt I think I’ve figured it out. I’ve created a plugin that sets a flag if there’s a mutation in a ::wrap-mutate, if it’s there, ::wrap-read will get the new db value, and reset the flag. feels a little clunky but it seems to work


@pvillegas12 hello, are you using the latest pathom? I did a release this week that did some changes to the elide-not-found plugin


Yeah @wilkerlucio I am on the latest one, the problem was the encoding of large datomic ids


I’m basically switching over to uuids for all entities


I remember you discussed this before @wilkerlucio do you have :entity/id per each entity in your system or do you have a shared :model/id that is a uuid?


one per entity, think of then as a first "filter", the name narrows the scope you have to search for it, but that can depend on how the db is modeled


in my use case I'm dealing with other micro services mostly, so they already have identifiers before me, and we use those


the filtering just sold me 100% on uuids per entity type 😄


hi, i’m running into a weird problem, running at the REPL.


i’d noticed that the first time i’d call a newly instantiated parser


there’s a bit of a lag (~ 5 secs), but subsequent calls are snappy. However, I noticed that if I don’t make a call for few mins, then try it again, I see that same lag. was wondering if there’s some sort of cache that might be timing out?


might be datomic ion


this stuff isn’t ‘ionized’ yet, just running in the repl and it’s making client api calls to the server. But I forgot to mention that I’d also wrapped the resolver bodies with (time) and have verfied that they aren’t the issue. Getting the same performance from them even when the calling the parser is ‘slow’


@eoliphant morning, had you tried tracing these slow requests to check what might be going on? 5s to run doesn't sound normal


yeah that my next question. Wasnt clear on how to get the tracing data while running from the the repl. I’ve done some simple checking like, wrapping the involved resolver bodies with (time) and have been able to verify that their performance is consistent


ok nvm, just figured out how to add the :com.wsscode.pathom/trace key to the query. Well this is fun lol, seeing the same behavior even when that’s the only key. And the trace-results seem to indicate that what pathom is doing is pretty snappy hmmm… will keep digging


Ok I think I was misreading it before. So @wilkerlucio if I’m reading this correctly, going from reset-loop to process-pending took about 5 secs?


and in a ‘good’ one that same jump is like 50 msecs

{:event "reset-loop",
                                       :duration 0,
                                       :start 4,
                                       :loop-keys [:com.wsscode.pathom/trace]}
                                      {:event "process-pending",
                                       :duration 0,
                                       :start 51,
                                       :provides #{[:fm.user/id #uuid"156e2937-5cf9-46fa-bbe6-8e9d9e1f3780"]},
                                       :merge-result? true}


@eoliphant are you using fulcro inspect? you can get a much more detailed timeline view from there, its a lot of data to read by hand 🙂


but that process pending is something that happen in side, so its the sum of the time some things happen before it, so not enough to know why it was slow


yeah, i have it but, don’t have the ui plumbing in place yet, probably will just do that lol


yeah, i’m learning as a go here lol


and I’ve now ‘traced’ it here


:key :fm.user/first-name}
                                                              {:event "call-resolver",
                                                               :duration 5061,
                                                               :start 2,
                                                               :label :fm/user,
                                                               :input-data #:fm.user{:id #uuid"156e2937-5cf9-46fa-bbe6-8e9d9e1f3780"},
                                                               :sym :fm/user,
                                                               :key :fm.user/first-name}


one thing that I see weird, why is :sym a keyword?


resolver names must be symbols


ok now i’m just annoyed lol, it looks that that resolver code is doing something wonky. I’d just timed the datomic call but something else weird is going on


dammit lol, will fix that


Im curious, how/why you get a keyword as a resolver name?


i’m generating datomic schema, a bunch of resolvers, etc from this generic data model


just a bug in that converter


i need to get them all spec’ed


pathom has specs for most of the things, you can just do some (s/valid? (s/keys) x) check when you generated then, and pathom ns keywords will get validated


yeah, I saw that when I was poking around 🙂 which is super helpful

🙂 5

side note, i wanted shoot you some doc PR’s But I’m getting the following error asciidoctor: WARNING: index.adoc: line 2691: include file not found: /Users/erichkoliphant/Dropbox/projects/pathom/src-docs/com/wsscode/pathom/book/graphql/fulcro_network/graphql_todo.cljs I created a feature branch off of develop in my fork, so it should be good in that respect


humm, strange, this example is not in my source either


maybe a bad link in the docs, we can remove this link


and improvements on docs are very welcome 🙂


also, did you see my note about needing to refresh the datomic db in my env in order to make mutation joins work? I’d been working all day and cobbled together a solution, but now with some sleep and coffee, I see some other potential issues. To fix the issue, instead of just passing in {:db db :conn conn} I now pass in an atom on its own key that looks like {:db db :conn conn :reset false}. Have a plugin (really great architecture on that BTW, super easy to use once you ‘get it’), that on wrap-mutate sets the :reset flag to true, and my wrap-reset if the flag is set, I swap in a new db value. and in either case, set the top-level :db key to the db from the atom. It works, but feels a little ah deselegante lol. My other concern is the ‘contract’. part of datomic’s value, especially for something like pathom/graphql is that I can run N disparate resolvers against the same DB state. In this case, while the mutation join now works fine. I’m not sure about the behavior when I send over say a mutation with a join, plus some number of queries.


ok, cool, I’ll just yank that reference from the .adoc