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.

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

Got my answer: https://groups.google.com/forum/#!topic/datomic/wBRZNyHm03o

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: "java.net.SocketTimeoutException: connect timed out: 209.177.90.158:4335" [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!