This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (2)
- # beginners (80)
- # boot (18)
- # cider (6)
- # cljs-dev (14)
- # cljsrn (5)
- # clojure (114)
- # clojure-android (5)
- # clojure-dev (8)
- # clojure-greece (6)
- # clojure-italy (9)
- # clojure-russia (108)
- # clojure-uk (82)
- # clojurescript (158)
- # css (1)
- # cursive (21)
- # data-science (1)
- # datomic (66)
- # emacs (9)
- # ethereum (3)
- # fulcro (26)
- # graphql (7)
- # hoplon (25)
- # juxt (2)
- # keechma (34)
- # lein-figwheel (4)
- # leiningen (2)
- # off-topic (4)
- # om (5)
- # onyx (14)
- # parinfer (2)
- # pedestal (17)
- # planck (3)
- # portkey (14)
- # re-frame (23)
- # reagent (12)
- # ring (8)
- # rum (1)
- # shadow-cljs (506)
- # spacemacs (2)
- # vim (11)
- # yada (6)
is there an idiomatic way to determine the previous transaction? like opposite of
(dec some-tx-id) seems to work, I suppose thats idiomatic (if I understand transactions well enough)
just a quibble, but monotonically does not mean no gaps. 3,3,3,3,4,4,4,5 is monotonically increasing, as is the same sequence with gaps. Monotonic means that each term in the sequence is greater than or equal, not "contiguous"
Can anybody explain why, in the client API, pull manages to work without being passed the connection? I understand (thanks, @marshall!) that queries are processed on the peer server, but how is it that pulls are processed locally? I can conceptually understand the difference, but why was the local/remote line drawn between pull and query?
The distinction is that queries MUST be evaluated somewhere,
conn is where to evaluate it
You can have a query that has no inputs or multiple dbs as input, but it still needs to run somewhere
pulls need to run on the peer server, but the source of the db object is the same as the connection is the same as where it runs. there is no ambiguity
The key to me seems to be the “no input” or “no dbs” input case -then how to find the connection? So that is why query requires conn as an arg. Does that reasoning seem rational?
Really, its that query is an RPC. the database inputs (if any) are sent "by-reference" to the conn
This makes more sense if you compare with the peer api. Queries run locally in the peer api
Yes. And that is how I got confused. I assumed it was a question of a dependency on datalog.
in client, these are all routed through the peer server too, which also provides query
Here’s the part I still don’t get: a db value (on the client) specifies the database (storage access), but as far as I can see it does not say how to connect the the peer server. So without a connection, how does the pull fn know how to reach the peer server?
there's either a hidden reference in the db, or a process-level global that can find the connection for a db. It's an implementation detail in any case
But if the connection can be inferred from the db (by a global?) on pull, why not on query? That would make the
q args closer to the peer as well.
what I mean is, dbs come from connections from different endpoints, mixed together in the same query
Well, you only pass one connection so I don’t think so. But that does raise an interesting question: if I pass two dbs (from different servers) to a peer
as long as the peer server can access that storage it should be possible for it to execute the query
On a similar note, I found it interesting that pull can’t work on an arbitrary set of datoms -like query can.
I tried passing the
:tx-data of a transaction to pull but it didn’t work (because, presumably, there was no indication of where to send the work/contact a peer server)
you need to supply something that admits of d/datoms-like calls to it. (whatever the internal interface is)
And, another question: is there a spec or documentation somewhere for the
:tx-data key returned from a transaction?
Presumably in the order provided as input, modulo the obfuscation that entity map form introduces.