Anybody running datomic on ECS / docker?

^ @potetm @devn order in a transaction is not guaranteed to be preserved, only order b/t transactions. I.e. the contents of a transaction are not a procedure and the serializable aspect of ACID only applies to the transaction as a whole. The order of datoms in a transaction doesn’t matter.

^ @devn it might be useful to see a cleared illustration of what’s going on, but from the description above it looks like you’re treating Datomic as a document store for logs, which is really not the best use or the way to get sequential time semantics within a log.

I'm surely abusing it.

This is not going to production, just playing at the moment.

@devn I think the standard use you’d see for logs in Datomic would be something like this: (1) parse a log file, generating time stamps and information of interest per log line of interest. (2a) transact one line per transaction, or (2b) add your own timestamp (inst) field as an attribute in the database. The same would apply if you wanted to preserve line numbers, for example.

not really unlike lexing in general, but parsing into transactions

the idea is that Datomic stores information, often already extracted from elsewhere, you’ll run into perf issues or hit a mismatch in semantics using it for raw data.

i.e. in this case if line is meaningful, and I want line context, I’d want to preserve the line so I could do +5, -5 on a line attribute, not try to reverse engineer the line context by extracting information from the log and reassembling it.

Is there a way to distinguish between the bind address for Datomic and the address it writes to the database? Both seem to be based on the host= parameter.

I've managed to deploy Datomic on AWS ECS (docker) but I don't see a way out on this ip issue.

@gerstree: you can use alt-hostto do this. This is an undocumented property that we’ll be adding to the docs. The host and alt-host settings were designed for AWS, where machines have internal and external IP addresses. On the Datomic AMI the AWS host is used for the (more efficient) internal IP, and alt-host is used for the (more broadly reachable) external IP. The transactor will bind to the port specified by host, and advertise its reachability at both host and alt-host. If host and alt-host are both specified, peers must resolve each of them to the same actual transactor if they resolve them at all. The peer will try to connect, first to host, and then if that fails to alt-host.

@bkamphaus Thanks, trying it right now.

It's quite a roundtrip (building / pushing / pulling) I will be right back with the results.

But it will be awesome once I get it running

@bkamphaus: working! Thank you so much

That's a working datomic on AWS ECS deployed via AWS Cloudformation.

@gerstree: cool, glad that resolved your issue :)

Peers are showing stack traces for the 'primary' address during startup, that's the only glitch I see.

No measurable delay in the failover to the second ip.

@bkamphaus: Good to know. Thanks for chiming in!