I mean I'm putting the host as an EC2 public DNS, if I was to restart the instance or decide to upgrade and the host name changed, would i recover ?

Are you putting your transactor on the internet available externally?

Also did you roll your own AMI for the transactor? Or did you use Datomic's provided AMI?

rolled my own AMI and it's only available in-network

there's a firewall

Don’t use it as an external id

Thanks for your reply. Could you please provide more reasoning behind this?

You can’t control them, e.g. reassert them into a different datomic db

Thanks. Are you maybe aware of any recommendations for external ids using Datomic Cloud?

random UUIDs are a safe bet, and they have the nice property that you know them before you transact them which reduces coordination headaches

This is what I use and was wondering if there is anything better. Thanks for sharing your knowledge.

db/id can change in operations like backup/restore, and you can't control it I already used :db/id for external operations, like form submissions. I think that for these cases is OK to use db/id's because it is short-lived interactions But for things like URL's, never use it.

I would still use squuids instead of random ones. The docs say you can get away with random, but they still affect things in large databases. I’m using https://github.com/yetanalytics/colossal-squuid

Thanks souenzzo. @U0CKQ19AQ funny that you mentioned colossal-squiid as I was looking at https://github.com/danlentz/clj-uuid, which seems to have similar functionality -- it's only CLJ.

What's the advantage of colossal-squuid over (datomic.api/squuid) ? @U0CKQ19AQ

I thought colossal-squuid could control which timestamp to use, but no. But it is not tied to datomic jars that can be problematic to distribute and is written in .cljc.

And yes, don't use :db/id:s (i do it myself in a certain part of the system but will of course regret it later). A separate id is also convenient when doing decantering (selective rewriting) and other transformations of the database.

(datomic.api/squuid) is not available in Datomic Cloud

squuids are no longer required in Datomic, as per this discussion (because of adaptive indexing) https://forum.datomic.com/t/why-no-d-squuid-in-datomic-client-api/446/2

Yep, that’s what the docs say, and it is “truthy”. But if you use UUIDs as a standard unique identity on entities, it is HIGHLY recommended

It boils down to the fact that most databases use “recent” data. So in, say, an VAET index you’d like all of your “recent” stuff to sort together, and be likely to be grouped into segments that will likely already be in RAM. I was told, specifically, by Cognitect, that I should be using SQUUIDs in Cloud just a few weeks ago.

I was originally using random ones because of the exact doc you’re quoting