Fork me on GitHub
#datomic
<
2018-10-21
>
eoliphant17:10:02

ok.. I have a pretty weird problem. I have some ion code that runs a query and i'm getting different behavior on the server vs running the same code locally via a repl. I've done all sorts of testing, dumped my params map to a string, edn parsed it and re-run the same code in the repl, dumped the param types to make sure that nothing weird was happening there, but so far, again, calling the exact same function (which just calls a query and flattens the result) with the exact same parameters is behaving differently on the server (incorrectly) vs the client Ok, I think this might be a bug. I noticed I had some other code with virtually the same query, that wasn't exhibiting the same behavior. Ultimately the only difference between the two was that the one that is misbehaving was only returning a bound entity id, where the other was using it in a pull such that basically

; returns seq of ids on client, empty seq on server for exact same :where, params, etc
(d/q '[:find ?o  ...

; as expected identical behavior on client and server 
(d/q '[:find  (pull ?o [...])...

; working around the first with something like following works fine
(->> 
 (d/q '[:find  (pull ?o [:db/id])...
flatten 
(map :db/id)

eoliphant17:10:30

@U1QJACBUM did you guys see this?

jaret18:10:05

@U380J7PAQ Hey! Just saw this. I am not sure I am following you on the use of “client” and “server” here. Are you saying that you are noticing a different behavior between invoking a query on Ions and a local repl? Or, are you referring to a difference between on-prem/peer-server and client? Do you have a full gist showing what you’re running and where?

eoliphant18:10:18

sorry I wasn't clear. Yes, that's exactly it. Seeing this behavior in local REPL, tunneled to server, vs on the server itself.

jaret18:10:53

Ok so if I write some queries as above and invoke them with query and connected directly to the stack via REPL I should see different behavior?

jaret18:10:15

If that’s the case, I’ll go reproduce and figure out what’s going on here.

eoliphant18:10:39

yeah that's what I was seeing. Here's the actual full code

(defn get-all-results
  [db {:keys [run/number primer-pair/pair-id sample/extid customer/cust-id]
       :as params}]
  (cast/event {:msg "get-all-results"
               ::params [number pair-id extid cust-id]
               })
  (->>
    (d/q '[:find #_?o (pull ?o [:db/id])
           :in $ ?run-num ?pp ?samp-id ?cust-id
           :where
           [?r :run/number ?run-num]
           [?p :primer-pair/pair-id ?pp]
           [?s :sample/extid ?samp-id]
           [?u :customer/samples ?s]
           [?u :customer/cust-id ?cust-id]
           [?o :otuabund/run ?r]
           [?o :otuabund/primer-pair ?p]
           [?o :otuabund/sample ?s]
           ]
      db number pair-id extid cust-id)
    flatten
    (map :db/id))
  )

eoliphant18:10:55

with my 'fix'

eoliphant18:10:09

it's super weird

jaret18:10:17

Roger! I’ll go digging in.

eoliphant18:10:44

but uncomment the ?o comment the pull, take out the map i see the behavior

eoliphant18:10:53

i ran a ton of tests

eoliphant18:10:11

created a quick wrapper ion

eoliphant18:10:21

so I could test it from the lambda console

eoliphant18:10:51

because it was being called from an API and what have you. so wanted to get that out of the loop. But once I got it stripped down, the pull version worked, if I pushed the one that just returned the id it failed

joshkh23:10:25

totally inconsequential because it's not used, but there's a typo in the Datomic/ion-starter example. https://github.com/Datomic/ion-starter/blame/master/src/datomic/ion/starter.clj#L97 "contect" should be "context"? I tried to create a PR but i don't think they're accepted upstream so dropping a note here. 🙂

jaret01:10:27

Thanks for report/catch. I’ve fixed it.