Fork me on GitHub
#datomic
<
2017-02-02
>
devth16:02:05

are db/ids guaranteed to never change? e.g. during migration from one underlying storage to another, or some maintenance event that i'm not aware of. trying to determine if i should rely on them for things like URLs

pesterhazy16:02:39

I think the conventional wisdom is that you shouldn't rely on entity ids

pesterhazy16:02:19

They might change in future versions of datomic, perhaps due to repartitioning (but that's not happening currently)

pesterhazy16:02:57

Even now, they make it hard to re-import a dataset

potetm16:02:10

It's very much a "datomic internally managed id".

pesterhazy16:02:47

Entity ids don't change when restoring a backup, but when you build your own backup/restore solution (for a partial database), you'll end up with a new set of entity ids

pesterhazy16:02:31

A good strategy is to pick a primary key and to use lookup refs

potetm16:02:41

They don't allow you to set it. So anything shared externally than needs to move from Database A to Database B should have another id assigned.

pesterhazy16:02:59

[:user/guid #uuid "..."] is a drop-in replacement for entids almost everywhere

devth16:02:17

right. this all makes sense. thanks!

pesterhazy16:02:33

you're welcome!

sova-soars-the-sora23:02:10

I have a beginners' question... how can I do a d/transact and also get the entity ID as a result / return val?

favila23:02:38

Make a tempid, keep it, transact, keep the :tempids result, then use that function to get a real entid from the two

favila23:02:13

(note I rarely do this anymore, using upserting attrs and refetching by lookup ref is what you want to do most of the time)

wei23:02:17

is there a good answer yet for using spec on EntityMaps? s/keys fails because an EntityMap is not a map?

sova-soars-the-sora23:02:58

@favila thanks! I was just coding up the same thing (d/transact and then do a query to get the entity id)

sova-soars-the-sora23:02:19

the joy of clojure is real ! 😃