Fork me on GitHub

Hi, i’m making some changes to an app, and I’ve added a ‘gid’ attribute that I’m setting to a squuid. do people generally set it to the datomic string or uuid type? I’ve used the uuid type and queries, entity refs, etc don’t seem to match against raw uuid strings.


We use the uuid type. You are correct, datomic does not match different types, you need to make a real uuid object in lookup refs, queries etc


Ok, so just java’s UUID.fromString(), etc?


Yes. There is a reader literal too, #uuid


ah right. But not sure how to ‘apply’ to a variable, I just added something like (let [myuuid (UUID/fromString myid]).. Not clear on how to use #uuid in this context


That's only for literals. If you want a string in a var to be uuid-ed, do what you are doing


ok gotcha, that’s what I thought, but didn’t know if there was some clojure trickery that I was unaware of lol. thanks


BTW, I’m using a variant of your dynamic schema approach from the mailing list. Very cool, gets very meta, very quickly lol, but Datomic makes everything so much easier. Working on replacing a homegrown forms system that smushes EAV and forms behavior into an unholy marriage of Oracle tables, PL-SQL and Java. It does a lot of stuff, but I’ve gotten a fair representation of their core model worked out with a couple days’ thinking and an afternoon of coding


Hi! The Datomic transactor requires port 4335 and 4336 to be accessible in addition to port 4334? I was trying to run it inside a docker container and had a connection timeout error until I exposed & forwarded ports 4335-4336


Hi! Is there anyone around who could help me debug a connection issue to a transactor? I am trying to run a datomic-pro-starter transactor on a server (in a docker container) but getting a connection timeout error when I try to connect to it from my machine


I exposed ports 4334, 4335 and 4336 (proprly I think) and even set alt-host to the public IP assigned to the container, but no luck yet


java.util.concurrent.ExecutionException: org.h2.jdbc.JdbcSQLException: Connection is broken: " connect timed out:" [90067-171]


Problem solved!


Hello again. Quick question: could anyone tell me how performant “asOf” queries are if the timestamp may vary widely between queries? (e.g. building a web app where users can see the state of their document at any point in time). I suspect it might cause performance issues if the indices are not built for this type of use


@hmaurer this is precisely the sort of thing Datomic is built to be good at. go forth 🙂


@robert-stuttaford thanks! just wanted to check. There was the possiblity that datomic was built to keep a full history for auditing purposes but not for frequent querying at various points in time


well, it’s that too 🙂 we certainly use it both ways!