Fork me on GitHub
#datomic
<
2024-06-29
>
kokonut11:06:40

i have a basic question. based on the example on this doc, https://docs.datomic.com/peer-tutorial/query-the-data.html,

(d/q all-movies-q db)
#{[17592186045420] [17592186045421] [17592186045422]}
entity ids seem to be integers, which are sequential. i wonder why datomic uses sequential data rather than uuid. wouldn't it expose to some security risks? or is it customary to add a user-defined id (e.g. in uuid) to the schema?

cjohansen11:06:37

Since you do not control entity ids you should treat them as an implementation detail and not use them outside your system. So, yes, adding additional identifiers for any content you need address externally is a good idea.

👍 1
souenzzo14:06:29

also, you should not expose :db/id's in you API it is ok-ish to use. But once you don't control it, it is not a good idea. For example, db/id's may change after a backup restore process.

kokonut14:06:22

Yes, that totally makes sense.

Ivar Refsdal21:06:43

> For example, db/id's may change after a backup restore process. Really? Is that documented somewhere?

chrisblom18:07:20

for all entities that are expose to the outside (in api's, url's etc), i used to set up a unique external id property (:external/id) and use that.

👍 1
kokonut08:07:55

But fields of ref type hold db/id of other object. I am not sure how not to expose it at all practically speaking.

kokonut08:07:02

And also, even if I additionally set up :external/id that only engages the object itself but can't do anything with referencing to other object.