This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-10
Channels
- # adventofcode (3)
- # aws (2)
- # beginners (85)
- # boot (8)
- # boot-dev (4)
- # cider (36)
- # clara (3)
- # cljs-dev (87)
- # cljsrn (3)
- # clojure (87)
- # clojure-austin (12)
- # clojure-brasil (1)
- # clojure-dev (8)
- # clojure-dusseldorf (5)
- # clojure-estonia (5)
- # clojure-greece (4)
- # clojure-italy (3)
- # clojure-spec (17)
- # clojure-uk (55)
- # clojurescript (70)
- # core-logic (2)
- # cursive (6)
- # data-science (18)
- # datomic (13)
- # emacs (34)
- # fulcro (347)
- # graphql (12)
- # hoplon (6)
- # jobs (3)
- # jobs-discuss (43)
- # juxt (2)
- # keechma (31)
- # leiningen (29)
- # lumo (2)
- # midje (2)
- # off-topic (118)
- # om-next (4)
- # onyx (39)
- # pedestal (6)
- # re-frame (85)
- # reagent (21)
- # remote-jobs (3)
- # ring (5)
- # rum (2)
- # shadow-cljs (126)
- # spacemacs (1)
- # sql (6)
If the query bit is quoted, you need to pass your values into it, like:
(d/q '[:find
(pull ?e [:job/doc-num num])
:in $ num
:where
[?e :job/job-num "01"]]
db (:job/filing-date :default ""))
Thanks @timgilbert.
I'm trying to run a transactor on Heroku. The transactor is up and running and my peer can connect to storage to retrieve the host
and alt-host
values, but it cannot connect to the transactor. I can't telnet to the transactor using its port either. Can anybody help with this? I suspect it's similar to running a dockerised setup.
ActiveMQNotConnectedException AMQ119007: Cannot connect to server(s). Tried with all available servers. org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory (ServerLocatorImpl.java:799)
The full error looks like this:
ActiveMQNotConnectedException AMQ119007: Cannot connect to server(s). Tried with all available servers. org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory (ServerLocatorImpl.java:799)
clojure.core/eval core.clj: 3206
...
user/eval2432 REPL Input
datomic.api/create-database api.clj: 19
datomic.Peer.createDatabase Peer.java: 117
...
datomic.peer/create-database peer.clj: 764
datomic.peer/create-database peer.clj: 772
datomic.peer/send-admin-request peer.clj: 752
datomic.peer/send-admin-request/fn peer.clj: 760
datomic.connector/create-transactor-hornet-connector connector.clj: 320
datomic.connector/create-transactor-hornet-connector connector.clj: 322
datomic.connector/create-hornet-factory connector.clj: 142
datomic.connector/try-hornet-connect connector.clj: 110
datomic.artemis-client/create-session-factory artemis_client.clj: 114
org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory ServerLocatorImpl.java: 799
org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException: AMQ119007: Cannot connect to server(s). Tried with all available servers.
type: #object[org.apache.activemq.artemis.api.core.ActiveMQExceptionType$3 0x5d70be8d "NOT_CONNECTED"]
clojure.lang.ExceptionInfo: Error communicating with HOST 0.0.0.0 or ALT_HOST on PORT 3206
alt-host: ""
encrypt-channel: true
host: "0.0.0.0"
password: <redacted>
peer-version: 2
port: 3206
timestamp: 1515588947255
username: <redacted>
version: "0.9.5561.50"
I realise this is probably a networking problem, but I've been trying to get a Datomic transactor running for a long time now and still haven't managed it.
Maybe something in here is responsible, such as TCP routing? https://devcenter.heroku.com/articles/http-routing#not-supported
Probably like some other people, I am curious how the architecture of a single Transactor affects performance. Does the Transactor have any multi-threaded aspects (like accepting data from Peers in parallel)? Can someone draw a (conceptual) comparison of how the write performance of Datomic would compare to a regular SQL database (e.g. PostgreSQL)?
From a Rich HIckey talk I saw a few months ago: the Transactor does leverage several threads, but not via parallelism - via 'pipelining' instead. E.g one thread for unmarshalling the transaction requests, one for running the transactions serially, one (or maybe more) for indexing, one for sending updates to the Peers, etc.
A regular SQL database will use locking for coordination, i.e reads will slow down writes and writes will slow down reads. Datomic won't have this problem, however I reckon its indexing cost is probably higher - i.e for an extreme use case where you only ever want to write serially and not read, PG will probably have higher throughput.
It's important to say that if you application has TO MANY writes, it may not fit with datomic...
@U2J4FRT2T I would nuance this statement as follows: if your application has too much data / too many writes, not all of it can go in Datomic.
I wrote a bit about Datomic's performance characteristics here: https://medium.com/@val.vvalval/what-datomic-brings-to-businesses-e2238a568e1c