This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-04
Channels
- # admin-announcements (3)
- # alda (4)
- # beginners (30)
- # boot (116)
- # cbus (5)
- # cider (20)
- # clara (10)
- # cljs-dev (12)
- # cljsjs (41)
- # cljsrn (9)
- # clojars (6)
- # clojure (131)
- # clojure-bangladesh (5)
- # clojure-colombia (2)
- # clojure-dev (9)
- # clojure-ireland (4)
- # clojure-japan (3)
- # clojure-norway (10)
- # clojure-poland (6)
- # clojure-russia (59)
- # clojure-sg (1)
- # clojurebridge (2)
- # clojurescript (76)
- # clojurewerkz (4)
- # css (6)
- # cursive (21)
- # data-science (24)
- # datomic (27)
- # emacs (9)
- # hoplon (68)
- # jobs (2)
- # jobs-rus (1)
- # ldnclj (10)
- # lein-figwheel (9)
- # leiningen (21)
- # off-topic (5)
- # om (232)
- # onyx (63)
- # parinfer (2)
- # proton (25)
- # re-frame (12)
- # reagent (39)
- # untangled (6)
- # yada (122)
After a query, I listen to tx-report-queue
. How can I compute the difference between old result and new result, with the tx-data
that is provided in tx
? (PS. without re-run the query)
I see that 1.0.3 comes with the transactor, so I suppose that's the right one to use. The reason I'm asking is that we're having intermittent problems with connecting from Datomic peers to an otherwise well-behaved Couchbase 3.0.1-1444 cluster. The error messages look like this:
2016-03-04T16:48:40.35395 2016-03-04 11:48:40.352 WARN c.c.client.CouchbaseConnection - Closing, and reopening {QA sa=prd-useast-couchbase-config-node-01.node.us-east-1.consul/10.51.155.229:11210, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: 0 Opaque: 4 Key: pod-catalog, topWop=null, toWrite=0, interested=1}, attempt 0.
2016-03-04T16:48:40.35399 2016-03-04 11:48:40.353 WARN n.s.m.p.b.BinaryMemcachedNodeImpl - Discarding partially completed op: Cmd: 0 Opaque: 4 Key: pod-catalog
2016-03-04T16:48:40.40825 2016-03-04 11:48:40.407 WARN c.c.client.CouchbaseConnection - Node exepcted to receive data is inactive. This could be due to a failure within the cluster. Will check for updated configuration. Key without a configured node is: pod-catalog.
2016-03-04T16:48:42.35671 2016-03-04 11:48:42.356 WARN n.s.memcached.auth.AuthThreadMonitor - Incomplete authentication interrupted for node {QA sa=prd-useast-couchbase-config-node-01.node.us-east-1.consul/10.51.155.229:11210, #Rops=0, #Wops=2, #iq=0, topRop=null, topWop=Cmd: 0 Opaque: 5 Key: pod-catalog, toWrite=0, interested=8}
2016-03-04T16:48:42.35758 2016-03-04 11:48:42.357 WARN net.spy.memcached.auth.AuthThread - Authentication failed to prd-useast-couchbase-config-node-01.node.us-east-1.consul/10.51.155.229:11210
@tcrayford: thanks for the pointer re: TOAST. Didn't know this was what I was wondering about.
what’s a good way to a keep global config value in datomic? i.e. a property that only has one value
Why not just define an attribute to name that config value and define its type, and then have a single entity with that attribute?
oh, I think I get what you’re saying. the lookup for that value would be annoying though, right?
I'm still in the head-wrapping stage as well, so you should take my thoughts with a grain of salt.
But..., basically there are two entities you want to create, I think.
1. The schema entity which defines a new kind of attribute.. Let's say it's name (it's "ident") is :mysystem/config
.
You only need to create this one the database initialization stage, as part of the usual schema definition.
Then, there's also,
2. An entity which has no purpose except to have this attribute.
When you change the system configuration, you would add/retract assertions about this second entity.
I don't see why lookup would be any more or less annoying than lookup elsewhere in datomic.
(first (d/q '[:find ?config-value :where [?e :mysystem/config ?config-value]] db))
might be right.. not sure off the top of my head.
I'm just grabbing the first
query result since I assume that in your application logic you enforce that there is only ever one entity holding this value.
You could even give the entity an alias, and refer to it as :mysystem
, if you wanted to, and then maybe you could get easier lookup by using (d/entity :mysystem)
. Not sure.
For single-value-returning queries the .
is probably more idiomatic: (d/q '[:find ?config-value . :where [?e :mysystem/config ?config-value]] db)
@jgdavey: what is the .
formally in the query grammar? it's news to me.
Ah, thanks.
So datomic-free is directly available via maven. Is there also a way to download the datomic free transactor directly for non-interactive deployment, or is the only way to click-thru the EULA on the website?
@alexisgallagher: alias is a good idea, thanks