Fork me on GitHub
#pathom
<
2022-02-28
>
hjrnunes22:02:00

Hi! Can someone riddle me this, please? Why can I get to name in the last query but not in the first one? Thanks!

(require '[com.wsscode.pathom3.connect.built-in.resolvers :as pbir])
(require '[com.wsscode.pathom3.connect.indexes :as pci])
(require '[com.wsscode.pathom3.connect.operation :as pco])
(require '[com.wsscode.pathom3.interface.eql :as p.eql])

(def mock-accounts [#:gnucash.account{:id   "e8bb8cdcdd964239bc0255c447f5174d",
                                      :name "Root Account"}])

(def mock-transactions [#:gnucash.transaction{:id          "75d3cf61239f425c9d1d5da30ef56476",
                                              :description "Starting balance",
                                              :splits      [#:gnucash.split{:id       "c5b722950d5947508d1acb41526ee278",
                                                                            :quantity "203995/100",
                                                                            :account  "e8bb8cdcdd964239bc0255c447f5174d"}
                                                            #:gnucash.split{:id       "b677a56fa6574df5bab5963d362ce0b6",
                                                                            :quantity "-203995/100",
                                                                            :account  "e8bb8cdcdd964239bc0255c447f5174d"}]}])


(pco/defresolver gnucash-accounts []
  {:gnucash/accounts mock-accounts})

(pco/defresolver gnucash-account [{:gnucash.account/keys [id]}]
  {::pco/output [:gnucash.account/id
                 :gnucash.account/name]}
  (->> mock-accounts
       (filter (comp #{id} :gnucash.account/id))
       (first)))

(pco/defresolver gnucash-transactions []
  {::pco/output [{:gnucash/transactions [:gnucash.transaction/id
                                         :gnucash.transaction/description
                                         {:gnucash.transaction/splits
                                          [:gnucash.split/id
                                           :gnucash.split/quantity
                                           :gnucash.split/account]}]}]}
  {:gnucash/transactions mock-transactions})

(pco/defresolver gnucash-transaction [{:gnucash.transaction/keys [id]}]
  {::pco/output [:gnucash.transaction/id
                 :gnucash.transaction/description
                 :gnucash.transaction/splits]}
  (->> mock-transactions
       (filter (comp #{id} :gnucash.transaction/id))
       (first)))

(pco/defresolver gnucash-transaction-splits [{:gnucash.transaction/keys [id]}]
  {::pco/input  [:gnucash.transaction/id]
   ::pco/output [:gnucash.split/id
                 :gnucash.split/quantity
                 :gnucash.split/account]}
  (->> mock-transactions
       (filter (comp #{id} :gnucash.transaction/id))
       (first)))

(def env
  (pci/register
    [gnucash-accounts
     gnucash-transactions
     gnucash-account
     gnucash-transaction
     gnucash-transaction-splits
     (pbir/alias-resolver :gnucash.account/parent :gnucash.account/id)
     (pbir/alias-resolver :gnucash.split/account :gnucash.account/id)]))


(p.eql/process env
               {:gnucash.transaction/id "75d3cf61239f425c9d1d5da30ef56476"}
               [:gnucash.transaction/description
                {:gnucash.transaction/splits [:gnucash.split/id
                                              :gnucash.split/quantity
                                              {:gnucash.split/account [:gnucash.account/name]}]}])

;; =>
;; #:gnucash.transaction{:description "Starting balance",
;;                       :splits [#:gnucash.split{:id "c5b722950d5947508d1acb41526ee278",
;;                                                :quantity "203995/100",
;;                                                :account "e8bb8cdcdd964239bc0255c447f5174d"} ;; <----- NO NAME!
;;                                #:gnucash.split{:id "b677a56fa6574df5bab5963d362ce0b6",
;;                                                :quantity "-203995/100",
;;                                                :account "e8bb8cdcdd964239bc0255c447f5174d"}]} ;; <----- NO NAME!


(p.eql/process env
               {:gnucash.split/account "e8bb8cdcdd964239bc0255c447f5174d"}
               [:gnucash.account/name])

;; =>
;; #:gnucash.account{:name "Root Account"}  ;; <----- HAS NAME!

nivekuil22:02:59

try this query

(p.eql/process env
               {:gnucash.transaction/id "75d3cf61239f425c9d1d5da30ef56476"}
               [:gnucash.transaction/description
                {:gnucash.transaction/splits [:gnucash.split/id
                                              :gnucash.split/quantity
                                              :gnucash.split/account
                                              :gnucash.account/name]}])

hjrnunes22:02:23

Hi, yes I can see the right :gnucash.account/name values. Thank you!

hjrnunes22:02:36

But I'm struggling to understand what's going on...

hjrnunes22:02:24

Wouldn't I have to join via :gnucash.account/id explicitly?

nivekuil22:02:17

nope, your alias resolver is doing that mapping

nivekuil22:02:09

if you remove your alias resolver you can see it won't work at all, because :gnucash.split/account needs to have as its value a map, not a string, for pathom to understand it as joinable

nivekuil22:02:32

so :gnucash.split/account {:gnucash.account/id "e8bb8cdcdd964239bc0255c447f5174d"} instead of just the string ID

hjrnunes22:02:57

Ah that last one makes sense, yes

hjrnunes22:02:41

Thank you! That was really helpful!

nivekuil22:02:53

no problem! surprised to see anyone using gnucash

hjrnunes08:03:30

Yeah! I use it for my personal accounting. But I'm trying to get some bayesian transaction categorising going, so I need to scan the gnucash database to compile word frequencies. I thought Pathom could be useful for denormalising it

nivekuil22:02:59

with the new way errors are done, it seems a call to p.eql/process that used to be an exception (`All paths from an OR node failed`) now tries to print/serialize the whole env , which in my case is so big it causes the JVM to crash. not sure where the env is being added but is there a way to hide it from the error result?

jjttjj16:03:17

I have to second the request for the ability to hide the full env from the error info. Either that or it's been a reason to force me to be more conscious of what my tooling does with massive error data.

wilkerlucio17:03:28

hello folks, I cna surely consider some of those changes, but before I wonder if you guys considered using the boundary interface in this case?

wilkerlucio17:03:41

because the boundary interface will convert the errors in something less dreading ot send over the wire (that doesn't include full env)

wilkerlucio17:03:12

the reasoning for the full env in the process error is to allow underlying usages to have full context about the problem

jjttjj18:03:38

I hadn't used that yet but will look into it

wilkerlucio19:03:08

sorry, I said the wrong name, its boundary interface, docs here: https://pathom3.wsscode.com/docs/eql/#boundary-interface

wilkerlucio19:03:06

@U797MAJ8M and to answer you directly, env is getting add as part of the exception data on strict errors

nivekuil23:03:07

have not looked at the boundary interface yet, but I was crashing the JVM just debugging stuff in the REPL so I think it would not have saved me