Cursive can resolve macros for your like this:

Text version: Call the lightbulb menu with alt+enter on something that isn't resolved like >def or >defn (and also all the rad macros) and choose resolve .... as >

Fantastic - that fixed it! I'd seen this trick in the Fulcro videos but didn't think to apply it to the source files.. :man-facepalming: Thank you for the clear and detailed response.

sure thing, have fun coding!

Thanks for the report @UPWHQK562. Indeed something odd is happening with latest version and I’ll try to debug and fix when I get a chance (I’ll try today in the evening)

@UPWHQK562 I haven’t used xtdb checkpointing myself yet so I’m not sure if I would be able to help you with that, but would you mind sharing your xtdb config map? If you use in-memory storage for https://docs.xtdb.com/administration/1.19.0/configuring/#_storage I’m guessing it might lead to some data loss on restart - doesn’t checkpointing restore only index store https://docs.xtdb.com/administration/1.19.0/checkpointing/ ? :thinking_face: You could try calling https://docs.xtdb.com/clients/1.19.0/clojure/#_attribute_stats before and after restart to quickly glance if something changed there.

https://docs.xtdb.com/administration/1.19.0/configuring/#_nested_modules see this “important” section there that might explain confusing behavior: > The tx-log and document-store are considered ‘golden stores’. The query indices can, should you wish to, be thrown away and rebuilt from these golden stores. > > Ensure that you either persist both or neither of these golden stores. If not, XTDB will work fine until you restart the node, at which point some will evaporate, but others will remain. XTDB tends to get rather confused in this situation! > Likewise, if you persist the query indices, you’ll need to persist both the golden stores.

@pt.roterski You are correct. Thanks. I coincidentally switched over to using Postgres for the doc/tx stores yesterday, for performance reasons, and it appears the issue I reported above is corrected by that as well. That makes a lot of sense. Sorry! 😕 I'm still making sense of this modular DB landscape. I previously had configured just the index store to use something other than the in-memory store - trying to keep things as simple as possible so the learning scope is minimized - but this is checkpointing issue is where using persistent data stores became a necessity.

no worries 🙂 I’m glad that you managed to get this working and I’m happy to help (and coincidentally learn about checkpointing) 🙌

For what it's worth, the checkpointing config I'm using is the basic one suggested in the docs:

:xtdb/index-store {:kv-store {:xtdb/module "xtdb.rocksdb/->kv-store"
                                 :db-dir "/home/sheluchin/repos/proj/tmp/rocksdb/index-store/"
                                 :checkpointer {:xtdb/module "xtdb.checkpoint/->checkpointer"
                                                :store {:xtdb/module "xtdb.checkpoint/->filesystem-checkpoint-store"
                                                        :path "/home/sheluchin/repos/proj/.backups/xtdb/"}
                                                :approx-frequency "PT1H"}}}

yes, I usually like to separate the Pathom Mutation from the client mutation (separate namespaces) because I conceptually think of them as different layers

I do also rename most of my mutations, giving them more semantic names (similar to what we do for attribute keywords)

Thanks 🙂

in this way, I usually end up with 3 different names: 1. the full name for the pathom mutation (eg: com.acme.graph.domain/some-mutation) 2. the full name for the fulcro mutation (eg: com.acme.ui.domain.some-view/some-mutation) 3. the semantic name for the mutation (eg: acme.domain/some-mutation) Then, in the remote part of the Fulcro mutation I make it rename to the semantic name before sending to the server

just one tip, if you dont want the semantic naming, your example could be reduced to:

(ns app.mutations ...)

(defmutation fulcro-mut ...)

(pco/defmutation pathom-mut [...]
  {::pco/op-name `fulcro-mut}
  ...)

(on the op-name you don't need to say the ns, since the backtick will expand the symbol to the current namespace)

Ah, gotcha, thanks 🙂 In some ways it would be easier to keep pathom mutations/resolvers together with the rest of the database code in the same file, so I'm leaning your way.

Though, not sure Tony would agree 🙂 > Pathom lets you override the symbol on the server (via a `::pc/sym` options) but it is still a good idea to use the same actual namespace (via clj/cljs pairs or just a CLJC file) to "co-locate" the mutations for easier code navigation.

its a stylist choice in the end, so use whatever feels better for you 🙂

For me it's about ease of navigation. 100000 lines of code and you'll rather appreciate that you can just go to the ns of the symbol instead of having to remember some additional convention. Onboarding new people is also a concern if you stray from the "obvious"