Fork me on GitHub
#datomic
<
2020-03-02
>
pinkfrog01:03:33

I am using dynamodb, and am considering switching to datomic.

pinkfrog01:03:19

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?

pinkfrog01:03:05

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.

em08:03:52

@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.

pinkfrog08:03:14

cost-wise, does datomic incur more read/write requests?

pinkfrog08:03:40

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.

joshkh13:03:27

should it be possible to have two entities in Datomic with the same :db/ident but different :db/ids?

[{:db/id    111
  :db/ident :color/green}
 {:db/id    999
  :db/ident :color/green}]

ghadi13:03:07

do you see that in your database?

joshkh13:03:05

i do, and it's causing problems. i have entities referencing what should be the same enumerated value, but are in fact different entities.

favila13:03:44

could the history DB be involved?

favila13:03:57

how precisely did you produce those results you posted above?

joshkh13:03:37

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.

favila13:03:31

what is the result of (d/q '[:find ?e :where [?e :db/ident :color/green]] a-plain-current-db)?

joshkh14:03:31

good question! the weird thing is that when we query for the ident, we only get one result.

joshkh14:03:40

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}]

favila14:03:16

are those real entity ids?

favila14:03:29

is this real code?

favila14:03:36

please real code only

joshkh14:03:14

that's real code with the db/ids and db/idents replaced with other values

favila14:03:36

ok, then you should file a support ticket

favila14:03:50

(why the replacement? there’s nothing sensitive about entity ids)

ghadi14:03:53

and buy a lottery ticket at the same time

favila14:03:30

to prepare your ticket, get the full history of datoms for each entity

favila14:03:03

this is basically “impossible” so you’ve either stumbled on a really amazing bug, or you’re missing something

joshkh14:03:03

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. 🙂

favila14:03:10

use real code in your ticket at least. entity id details may matter

joshkh14:03:39

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.

souenzzo16:03:48

(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}

souenzzo16:03:47

"dynamic" keyworkding is evil 😈

joshkh18:03:46

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]

creeper 4
joshkh18:03:24

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 🙂

favila14:03:02

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.

favila14:03:13

there are many ways to cause 1 which won’t cause 2

favila14:03:16

so let’s rule out 2

daemianmack14:03:41

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?

John Conti20:03:56

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>

joshkh22:03:42

That looks correct to me, although you should be able to include the region if needed. Are you the very latest CLI version? They release an update not too long.