This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-14
Channels
- # asami (1)
- # babashka (50)
- # beginners (70)
- # bristol-clojurians (6)
- # calva (36)
- # chlorine-clover (1)
- # cider (4)
- # clj-kondo (3)
- # cljdoc (49)
- # cljsrn (5)
- # clojure (96)
- # clojure-australia (3)
- # clojure-dev (1)
- # clojure-europe (84)
- # clojure-nl (4)
- # clojure-spec (9)
- # clojure-uk (65)
- # clojurescript (31)
- # community-development (6)
- # conjure (17)
- # cursive (8)
- # datascript (5)
- # datomic (12)
- # duct (3)
- # emacs (18)
- # figwheel-main (2)
- # fulcro (7)
- # helix (1)
- # jobs (3)
- # luminus (7)
- # off-topic (77)
- # pathom (3)
- # portal (1)
- # rdf (4)
- # re-frame (1)
- # reitit (4)
- # remote-jobs (4)
- # reveal (15)
- # rum (1)
- # sci (38)
- # shadow-cljs (22)
- # spacemacs (1)
- # specter (6)
- # sql (1)
- # test-check (1)
- # tools-deps (60)
- # vim (12)
is it normal for SOCKS4 tunnel failed, connection closed
to occur when running a query in the REPL during a :deploy
?
Q: is there a metric somewhere that shows the hit-rate for cached queries? I’d like to know if I accidentally add queries that are not cached in their parsed state
I have a question about using :db/ident
as an enum. In my model, a :session/type
is modelled as an enum of :db/ident
s, which works great when writing queries. However, there are times when I want to return the :session/type
to be consumed as a value like :type/online
, but I get the datomic id instead. Is there a way to get ident
s as values or should I just use a keyword instead?
You can just pull them: [{:session/type [:db/ident]} ...rest]
You can also just join them in your queries, say because you are finding tuples of entities and statuses:
(d/q '[:find ?e ?type-ident
:in $ ?e
:where [?e :session/type ?type]
[?type :db/ident ?type-ident]
...)
Does that help ^^?
just one thing to note, that will only return entities that have a :session/type value. i made a similar post about it here: https://forum.datomic.com/t/enumerated-values-in-tuples-are-only-eids/1644
no response in 11 days, so if you would find an answer to the question useful then perhaps give it a bump or a like 🙂
@love.lagerkvist you can do (d/pull db [(:session/type :xform :db/ident)] id) => {:session/type :type/online}
Using #eql libraries you can programmatically add it to all your refs
(defn add-ident-xform
[ident? query]
(->> query
eqld/query->ast
(eql/transduce-children (map (fn [{:keys [dispatch-key] :as node}]
(if (ident? dispatch-key)
(assoc-in node [:params :xform] :db/ident)
node))))
eqld/ast->query))
(add-ident-xform
#{:session/type}
'[:foo
{:bar [:session/type]}])
;; => [:foo {:bar [(:session/type :xform :db/ident)]}]
But as a #fulcro and #eql developer, I like to return :session/type {:db/ident :type/online}
because it allow you to include useful data for frontend like :session/type {:db/ident :type/online :label "OnLine" :icon "green-dot"}
We had the impression that sometimes the ion code we deploy using the datomic
CLI command takes awhile (a few minutes) to actually replace the previously running version.
We are using unreproducible deployments into a solo topology.
The issue is with a web-ion GET request, which is called through an APIGW, using their new HTTP API (instead of RESTful API) and integrating the datomic lambda as a proxy, using the v1.0 payload format.
All versions of tools and libs are the latest (as of yesterday).
Has anyone experienced anything like this?