Fork me on GitHub
Chris Bidler13:05:39

Question re: on-prem and datomic:ddb// uris - is there a way to support STS-mediated IAM roles (e.g., access-key, secret-key, token) using Datomic on-prem, or does the role used by Datomic systems have to be attached to an IAM user with programmatic access?

Chris Bidler13:05:26

I created a forum post about this question too, since that seems to be an emerging best practice:

Chris Bidler14:05:31

You know what, I think the main issue here is an abject failure of reading comprehension on my part. I will report back in one (1) Docker build/deploy cycle time.

Chris Bidler14:05:05

Yes - it was me misreading the docs and missing the line specifying that if you provide no aws_access_key or aws_secret_key in the URI, Datomic will fetch the credentials from the default chain, which works just fine. 😅


I'd like to be able to run tests against a clean database for code written for Datomic cloud. When running against the cloud instance I can create/delete databases as needed, but this doesn't seem possible when running a local peer server backed by the mem transactor. Is there a way to start/kill peer servers from code for test purposes?


It should be possible to create and delete databases willy-nilly with the mem:// transactor, our unit test suite does this kind of thing a lot


I don't think it's possible to dynamically change the dbs that a peer server is serving


I also am not sure you can serve a mem db from a peer server anyway


Peer server can indeed run mem dbs. Giving it a mem db URI at startup will cause the peer server to create and serve that mem db


Right. How can I start/stop peer servers from code?


for the first problem (can't reload peer server's server list) maybe you can figure out how to start the peer server directly (likely it's just a clojure function) and make your own peer process with a "reload" or "change dbs" side channel


this is just a slightly faster and more elegant kill-and-restart


Hello datomic slack. I'm seeing some strange behavior with :db.type/bigint attributes and queries. The issue involves storing values as clojure.lang.BigInt and querying as java.math.BigInteger (using the 'q fn). In the memdb, I have to query the type that I gave. Using a sql storage backend, I must query using java.math.BigInteger regardless. Using the 'entity fn and an ident ref I can query using either type for any storage.


I can kind of reason about why this might be, but the inconsistency was surprising.


This code reproduces the issue