Fork me on GitHub
#datomic
<
2022-01-10
>
jdkealy18:01:58

Is it possible to update the transactor host address ?

jaret19:01:26

@jdkealy You can set host and alt in the properties file. Is that what you mean?

jdkealy20:01:52

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 ?

jaret14:01:19

Are you putting your transactor on the internet available externally?

jaret15:01:39

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

jdkealy22:01:05

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

jdkealy22:01:11

there's a firewall

jacekschae21:01:45

Is it ok to use :db/id as external id? Is there anything one should be aware of? Differences between Cloud and On-prem?

favila22:01:53

Don’t use it as an external id

jacekschae22:01:41

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

favila22:01:10

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

jacekschae22:01:56

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

favila22:01:04

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

jacekschae22:01:10

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

souenzzo01:01:03

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.

tony.kay03:01:12

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

jacekschae06:01:28

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.

magnars10:01:23

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

Linus Ericsson11:01:58

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.

👍 1
Linus Ericsson11:01:26

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.

jacekschae12:01:19

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

👆 2
Jake Shelby22:01:04

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

tony.kay22:01:01

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

tony.kay22:01:57

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.

tony.kay22:01:16

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