@wilkerlucio: @arohner: you can also use d/with to dry-run the transaction and check that (-> tx-result :tx-data count (> 1)) to know if there will be any changes

there will always be one datom for the tx timestamp

we do this in our Onyx stats processing system to reduce noise

@robert-stuttaford: cool, I'll try that approach, thanks

great

@wilkerlucio @arohner A transaction which re-asserts existing facts will create a new Transaction entity in the log, but it will not contain the re-asserted Datoms.

@stuartsierra: thanks, that's nice to know

@bkamphaus: do you perhaps know why peer would connect to 127.0.0.1 even though i’m giving it an FQDN which resolves to the IP of a different server on the dev storage? driving me nuts!

bit of a shotgun approach, but trying @luke and @daemianmack too

the docs clearly show that a host must be provided:

Dev Appliance: datomic:dev://{transactor-host}:{port}/{db-name}

Well, first of all, definitely.not.localhost is in fact a subdomain of localhost 😄

But I'll presume that's not actually the string you're using

yes not the real string

i can ping the actual domain from the server in question and it resolves to the right IP

Hm. Aside from some crazy networking nonsense I can't think of anything that would cause that.

Can you temporarily change the port on your db connection string to something else? Then your error message would show whether its somehow resolving your domain to localhost, or using a different config entirely.

i was using /etc/hosts shortcuts before. let me make very sure it’s not a factor

yeah overriding in hosts would definitely explain what's going on.

ok. /etc/hosts eliminated. still happening

bizarre

yes. i’ll alter the port

interesting

so now it’s attempting the domain

switching back

with 4334 it’s back to localhost again

‽

That's strange. It could be a bug in Datomic, but Occam's razor says its something with how your application code is loading the connection string. A caching effect, or something. Maybe restart the JVM process if you haven't already? Put a println immediately before you call datomic.api/connect at the lowest possible level?

sorry, don't have any really good ideas.

if the transactor machine’s firewall is not allowing connections, perhaps the code that reports this error isn’t reporting the right string for domain?

the strace has hornetq close to the throw. perhaps it’s in HQ.

trying to validate the firewall rules independently now

actually, @robert-stuttaford, looking at the error messages, I think your first one isn't a problem with hitting storage at all

look how the error comes from h2.jdbc when you change the port, but is a standard wrapped exception if the port is correct

yeah, it’s a hornetq strace; it’s trying to connect to the transactor

ok. i’m pretty sure it’s a blocked nostril <BACKSPACE> port. thank you for the rubber ducking and apologies to all for the channel noise

@robert-stuttaford: the host in the URL is the storage host, the transactor writes its location in storage and then the peer connects to the transactor. What’s the host in the transactor properties file?

Sorry if I missed any details there, just a quick scan.

that’s exactly where i’m debugging now. it’s 127.0.0.1. it should be the public ip, right?

or can i cheat and use 0.0.0.0

number of bugs I've worked on at $dayjob this month that would be trivial to fix if we'd used datomic instead of postgres: 40. Fuck databases without history and transaction metadata

(nearly all of those take the form "which part of this 50k lines of code is modifying this data incorrectly")

language!

@robert-stuttaford: it should be an ip the peer can connect to the transactor with if you’re using e.g. a container or virtual instance that doesn’t know its IP until running, you might have to look into something like e.g. https://groups.google.com/d/msg/datomic/wBRZNyHm03o/0SdNhqjF27wJ

great, thank you ben. nice gas mask, by the way

that explains why I saw 127…. now. it was fetching that value from storage (which it could reach), and the transactor had put 127 there because of the props file

To confirm a bit of undocumented knowledge http://docs.datomic.com/clojure/index.html#datomic.api/connect For a SQL backend, any connection pooling needs to be handled in userspace by providing the appropriate :datasource, right?

And is connection pooling even necessary?

The latter question is more important.

http://stackoverflow.com/questions/31416378/recommended-way-to-declare-datomic-schema-in-clojure-application

If anyone can be of help

@val_waeselynck posted an answer

@val_waeselynck basically it is use conformity and read the blogpost from @tcrayford that's how I got it working

@mitchelkuijpers: thanks for the quick answer I'll give it a try then validate your answer

@val_waeselynck no problem if you need any more help let me know