Fork me on GitHub
#datomic
<
2018-06-20
>
stuarthalloway10:06:53

@dave.dixon I have found the db for (small group of) tests approach to be fine, esp when you break out as many pure functions as possible and test them with data in memory

octahedrion10:06:07

I'm trying to retract a unique identity on an attribute like this https://docs.datomic.com/cloud/schema/schema-change.html#sec-5

octahedrion10:06:23

but I get Server Error

octahedrion10:06:17

when I do this (d/transact conn {:tx-data [[:db/retract :thing/id :db/unique :db.unique/identity]]})

octahedrion10:06:14

where :thing/id is the :db/ident of my attribute which has a unique identity

octahedrion10:06:39

(I can do queries and other transactions on that connection)

marshall12:06:03

@octo221 can you look in your system logs (cloudwatch logs for the datomic system) for the error? You can search “Exception” to narrow it down

octahedrion13:06:14

@marshall

"Cause": "nth not supported on this type: Db",

octahedrion14:06:51

"Type": "java.lang.UnsupportedOperationException",
                "Message": "nth not supported on this type: Db",
                "At": [
                    "clojure.lang.RT",
                    "nthFrom",
                    "RT.java",
                    983
                ]

marshall14:06:11

can you share the exact transaction you’re issuing?

octahedrion14:06:56

(d/transact conn {:tx-data [[:db/retract :thing/id :db/unique :db.unique/identity]]})

marshall14:06:15

oh, your attr is actually called :thing/id

marshall14:06:22

i thought that was a placeholder 🙂

octahedrion14:06:33

yes! it's a test

marshall14:06:56

ok. let me look into it

octahedrion14:06:37

that attribute was previously transacted like this:

(d/transact conn {:tx-data [{:db/ident :thing/id :db/unique :db.unique/identity :db/cardinality :db.cardinality/one :db/valueType :db.type/keyword}]})

marshall14:06:21

@octo221 yes, i’ve repro’d that behavior - looking into it now

Chris Bidler14:06:46

Does Lambda the Ultimate log telemetry anywhere? My issue is that I have an Ion (`items-by-type` from the ion-starter repo, in fact) that I can successfully invoke at the Lambda console, and when I try to invoke it elsewhere I get an exception that the second datasource in the datalog query (so, the type passed in to items-by-type) cannot be found

Chris Bidler14:06:13

I’m trying to figure out if there’s a place I can see what the Lambda execution chain is “seeing” when I pass my invocation to it without having to build in the AWS SDK, set up CloudWatch logging API, etc. in the starter project just to put Received Lambda input object: {} in a log somewhere I can see it. 🙂

stuarthalloway14:06:45

where is "elsewhere"?

Chris Bidler14:06:13

An AWS AppSync query resolver

stuarthalloway14:06:50

I think you want logging in the ion code, not in the lambda

stuarthalloway14:06:54

coming in the next release

Chris Bidler14:06:47

Indeed, I do want logging in the ion code, but I was hoping to “get away” with finding the shape of the input data in the lambda so that I didn’t have to build the ion logging myself just for this PoC 😄

stuarthalloway14:06:53

that said, for now you could modify items-by-type to catch exceptions and return whatever additional info you want, and see the problem directly in the ion return

stuarthalloway14:06:08

or even have a separate "debug" lambda that does that ^^

Chris Bidler14:06:12

(especially since I did read you statement that unified ion logging was coming soon)

Chris Bidler15:06:36

Okay, so I’ve made quite a bit of progress and now I am getting back an anomaly report I don’t know what to do with at all, from what I believe to be a successful invocation of a Lambda ion:

Chris Bidler15:06:47

{
  "errorMessage": "No implementation of method: :->bbuf of protocol: #'datomic.ion.lambda.dispatcher/ToBbuf found for class: java.util.HashSet",
  "errorType": "datomic.ion.lambda.handler.exceptions.Incorrect",
  "stackTrace": [
    "datomic.ion.lambda.handler$throw_anomaly.invokeStatic(handler.clj:24)",
    "datomic.ion.lambda.handler$throw_anomaly.invoke(handler.clj:20)",
    "datomic.ion.lambda.handler.Handler.on_anomaly(handler.clj:139)",
    "datomic.ion.lambda.handler.Handler.handle_request(handler.clj:155)",
    "datomic.ion.lambda.handler$fn__4062$G__3998__4067.invoke(handler.clj:70)",
    "datomic.ion.lambda.handler$fn__4062$G__3997__4073.invoke(handler.clj:70)",
    "clojure.lang.Var.invoke(Var.java:396)",
    "datomic.ion.lambda.handler.Thunk.handleRequest(Thunk.java:35)"
  ]
}

Chris Bidler15:06:51

I …am not sure what to do to debug this further. If I munge my input test data to fail, I get back the output of a catch statement in my ion that looks how I’d expect. If I change the test input data to be correct, or invoke the ion via AppSync at the GraphQL console there, I get …that.

Chris Bidler15:06:30

this is my ion code:

Chris Bidler15:06:33

(defn items-by-type-gql
  "GraphQL Datasource input massager for items-by-type ion"
  [{:keys [input]}]
  (let [type (keyword (get (json/read-str input) "type"))]
    (try
      (items-by-type* (d/db (get-connection)) type)
      (catch Exception e (str "Exception: ["
                              (.getMessage e)
                              "], for input: ["
                              (str input)
                              "], resolved type data: ["
                              type
                              "]")))))

Chris Bidler16:06:46

and this is the “successful” input as Lambda console test data (the input that causes the anomaly report above: {"type": "hat"}

Chris Bidler16:06:30

while, at the REPL, this succeeds succeeds, meaning I get back an array of items: (items-by-type-gql {:input "{\"type\":\"hat\"}"})

Chris Bidler16:06:40

so for example if I execute the Lambda at the console with this test data: {"type":"vibranium_bracelet"}

Chris Bidler16:06:29

I get back: "Exception: [processing rule: (q__303 ?sku ?size ?color ?featured), message: processing clause: [?e :inv/type ?type], message: Cannot resolve key: :vibranium_bracelet], for input: [{\"type\":\"vibranium_bracelet\"}], resolved type data: [:vibranium_bracelet]" (note that the [] characters are inserted by my ham-fisted catch output and do not imply arrays here)

Chris Bidler16:06:46

so in the case where the input is malformed or the type is not found, I get back a catch that appears to show the input being processed correctly, but when the input is correct, I get a No implementation of method: :->bbuf of protocol: #'datomic.ion.lambda.dispatcher/ToBbuf found for class: java.util.HashSet Just to summarize and clarify. I will shut up now since I’ve eaten over a screen of everyone’s scrollback. 😇

octahedrion16:06:48

is there a way to pull all reverse refs to an entity ? I can only seem to get the first one

octahedrion16:06:01

I'm doing

(pull ?n [* {:edge/_node [*]}])
where there are several edges having the same :edge/node

marshall17:06:35

@chris_johnson your catch returns a str; it appears that the items-by-type* function returns a HashSet

marshall17:06:47

notice that the lambda in the example converts the items-by-type* return value to a json string

marshall17:06:29

@octo221 can you show the result of that pull?

octahedrion17:06:47

[[{:db/id 30711558787040342,  :edge/_node {:db/id 474989023200450  :edge/node {:db/id 30711558787040342}}}]]

octahedrion17:06:03

yet

(d/q '{:find [(count ?e)] :where [[?e :edge/node 30711558787040342]]} db)
=> [[6]]

Chris Bidler17:06:48

@marshall ah, yes! Thank you for being a second pair of eyes on The Obvious-in-Hindsight Mistake. 😅

Chris Bidler18:06:55

yyyyyeaaaaaahhhhh

🍾 4
denik19:06:05

FYI @marshall re: the issue I had yesterday, I works now but I don’t know why

denik19:06:47

is there a story for a webapp that uses datomic ion and websockets?

stuarthalloway20:06:30

we certainly intend to continue adding integration points

🚀 4