This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-02
Channels
- # aleph (1)
- # announcements (1)
- # babashka (4)
- # beginners (89)
- # calva (3)
- # chlorine-clover (18)
- # cider (33)
- # clj-kondo (27)
- # cljdoc (4)
- # cljsrn (2)
- # clojure (248)
- # clojure-europe (7)
- # clojure-italy (15)
- # clojure-nl (7)
- # clojure-norway (10)
- # clojure-poland (1)
- # clojure-spec (12)
- # clojure-sweden (5)
- # clojure-uk (57)
- # clojured (4)
- # clojuredesign-podcast (1)
- # clojurescript (55)
- # core-async (14)
- # core-logic (3)
- # cursive (10)
- # datomic (38)
- # figwheel-main (8)
- # fulcro (23)
- # graalvm (126)
- # hoplon (59)
- # jobs (1)
- # kaocha (3)
- # malli (30)
- # meander (17)
- # off-topic (32)
- # pathom (19)
- # pedestal (4)
- # re-frame (12)
- # reagent (2)
- # reitit (3)
- # shadow-cljs (81)
- # sql (9)
- # tools-deps (34)
- # vim (20)
- # vscode (7)
- # xtdb (5)
I wonder, if datomic will hurt the write and read performance. It seems datomic relies on some ec2 machine sitting in between the client and dynamodb. won’t that be some bottleneck?
other than the versioned history of the entire db and the query flexibility, I wonder what benefits datomic brings to me other than directly using dynamodb.
@i I switched from dynamodb to datomic, and it’s been great. While the underlying storage is indeed dynamo, you actually gain performance, not lose it, because of how queries are cached and how your application logic runs in Ions with direct access to memory. The query flexibility is great, and with Ions you gain a VPC and best practices for architecting an application, as well as easy integration into the rest of AWS with lambda triggers.
I am also concerned that, datomic seems to suffer single-point bottleneck on the ec2 instances. While with vanilla dynamodb, the bottleneck is only on the dynamodb site.
should it be possible to have two entities in Datomic with the same :db/ident
but different :db/id
s?
[{:db/id 111
:db/ident :color/green}
{:db/id 999
:db/ident :color/green}]
i do, and it's causing problems. i have entities referencing what should be the same enumerated value, but are in fact different entities.
nope, history isn't at play. i don't know how or when it happened. we just stumbled upon it today while chasing down a uniqueness conflict in an API.
what is the result of (d/q '[:find ?e :where [?e :db/ident :color/green]] a-plain-current-db)
?
good question! the weird thing is that when we query for the ident, we only get one result.
however...
(let [db (client/db)]
[(d/pull db [:*] 55555555555555555)
(d/pull db [:*] 10101010101010101)])
=> [#:db{:id 55555555555555555, :ident :color/green}
#:db{:id 10101010101010101, :ident :color/green}]
this is basically “impossible” so you’ve either stumbled on a really amazing bug, or you’re missing something
regarding sharing db/ids, i'd rather be safe than sorry. i can't think of anything i'd do with one, but you never know. 🙂
yes of course, always do in support tickets. just not in public channels with work-related db/ids. thanks for your input favila, i'll be sure to include any historical datoms.
(let [k1 (keyword "color" "green")
k2 (keyword "color" "green ")]
{:k1 k1
:k2 k2
:pr-str-k1 (pr-str k1)
:pr-str-k2 (pr-str k2)
:equal? (= k1 k2)})
=> {:k1 :color/green,
:k2 :color/green,
:pr-str-k1 ":color/green",
:pr-str-k2 ":color/green ",
:equal? false}
oh for sure, i've been bitten by that in the past. it was the next thing i checked 🙂
(let [db (client/db)
entity-1 (d/pull db [:*] 12345)
entity-2 (d/pull db [:*] 67890)
ns-name (juxt namespace name)]
[(-> entity-1 :db/ident ns-name)
(-> entity-2 :db/ident ns-name)
(= (:db/ident entity-1) (:db/ident entity-2))])
=> [["color" "green"] ["color" "green"] true]
and to add to the mystery, i can't query for either entity.
(d/q '{:find [(pull ?e [*])]
:in [$]
:where [[?e :db/ident :color/green]]}
(client/db))
=> []
anywho, ticket opened 🙂I want to tease apart two problems 1) these enum attrs are not pointing at the entities I expect 2) there’s actually more than one entity with the same :db/ident value.
also a quick check on the content of the db/ident seems in order — does A’s :color/green
value really equal B’s :color/green
value?
Anyone know how to report Datomic documentation bugs? I just found that https://docs.datomic.com/cloud/getting-started/get-connected.html has an error datomic client access system
is (I think) supposed to be datomic-access -r <AWS Region> client <Datomic System Name>