datomic

Ask questions on the official Q&A site at https://ask.datomic.com!
joshkh 2020-10-14T00:19:10.489Z

is it normal for SOCKS4 tunnel failed, connection closed to occur when running a query in the REPL during a :deploy?

steveb8n 2020-10-14T02:51:00.490100Z

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

motform 2020-10-14T12:41:35.493500Z

I have a question about using :db/ident as an enum. In my model, a :session/type is modelled as an enum of :db/idents, 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 idents as values or should I just use a keyword instead?

2020-10-14T13:38:41.493800Z

You can just pull them: [{:session/type [:db/ident]} ...rest]

2020-10-14T13:42:06.495200Z

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]
      ...)

1šŸ‘
2020-10-14T13:42:33.495400Z

Does that help ^^?

motform 2020-10-14T13:43:12.495600Z

Yes, that was exactly was I was wondering about. Thank you!

joshkh 2020-10-14T16:09:17.495900Z

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

joshkh 2020-10-14T16:11:07.496200Z

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 šŸ™‚

souenzzo 2020-10-14T17:41:15.499200Z

@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"}

onetom 2020-10-14T23:57:54.003Z

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?

onetom 2020-10-14T23:59:23.004Z

The :deploy-status reports SUCCESS for both keys in its response of course.