This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-20
Channels
- # beginners (94)
- # boot (8)
- # cider (21)
- # cljs-dev (3)
- # cljsjs (5)
- # cljsrn (10)
- # clojure (167)
- # clojure-italy (4)
- # clojure-norway (1)
- # clojure-russia (9)
- # clojure-spec (25)
- # clojure-uk (29)
- # clojurescript (20)
- # cursive (12)
- # datomic (55)
- # emacs (10)
- # fulcro (16)
- # graphql (1)
- # hoplon (18)
- # lein-figwheel (30)
- # off-topic (259)
- # onyx (8)
- # other-languages (13)
- # re-frame (1)
- # reagent (62)
- # ring (8)
- # ring-swagger (28)
- # shadow-cljs (187)
- # spacemacs (15)
- # specter (2)
- # testing (12)
- # tools-deps (38)
@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
I'm trying to retract a unique identity on an attribute like this https://docs.datomic.com/cloud/schema/schema-change.html#sec-5
but I get Server Error
when I do this (d/transact conn {:tx-data [[:db/retract :thing/id :db/unique :db.unique/identity]]})
where :thing/id
is the :db/ident
of my attribute which has a unique identity
(I can do queries and other transactions on that connection)
@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
"Cause": "nth not supported on this type: Db",
"Type": "java.lang.UnsupportedOperationException",
"Message": "nth not supported on this type: Db",
"At": [
"clojure.lang.RT",
"nthFrom",
"RT.java",
983
]
(d/transact conn {:tx-data [[:db/retract :thing/id :db/unique :db.unique/identity]]})
yes! it's a test
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}]})
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
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. 🙂
where is "elsewhere"?
An AWS AppSync query resolver
I think you want logging in the ion code, not in the lambda
coming in the next release
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 😄
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
or even have a separate "debug" lambda that does that ^^
(especially since I did read you statement that unified ion logging was coming soon)
thank you @marshall
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:
{
"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)"
]
}
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.
this is my ion code:
(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
"]")))))
and this is the “successful” input as Lambda console test data (the input that causes the anomaly report above: {"type": "hat"}
while, at the REPL, this succeeds succeeds, meaning I get back an array of item
s:
(items-by-type-gql {:input "{\"type\":\"hat\"}"})
so for example if I execute the Lambda at the console with this test data:
{"type":"vibranium_bracelet"}
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)
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. 😇
is there a way to pull all reverse refs to an entity ? I can only seem to get the first one
I'm doing
(pull ?n [* {:edge/_node [*]}])
where there are several edges having the same :edge/node
@chris_johnson your catch returns a str; it appears that the items-by-type* function returns a HashSet
notice that the lambda in the example converts the items-by-type* return value to a json string
[[{:db/id 30711558787040342, :edge/_node {:db/id 474989023200450 :edge/node {:db/id 30711558787040342}}}]]
yet
(d/q '{:find [(count ?e)] :where [[?e :edge/node 30711558787040342]]} db)
=> [[6]]
@marshall ah, yes! Thank you for being a second pair of eyes on The Obvious-in-Hindsight Mistake. 😅
@denik not yet