Fork me on GitHub
#datomic
<
2017-10-04
>
matthavener13:10:01

is there an idiomatic way to determine the previous transaction? like opposite of d/next-t

matthavener13:10:23

(dec some-tx-id) seems to work, I suppose thats idiomatic (if I understand transactions well enough)

favila14:10:17

there's no efficient way to determine the previous transaction

favila14:10:38

(dec some-tx-id) is actually wrong, tx ids do not increase monotonically

favila14:10:50

(there will usually be gaps)

dpsutton14:10:51

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"

cch118:10:58

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?

favila18:10:24

Pulls are processed remotely too.

cch118:10:21

How is that possible if the connection is not passed in?

favila18:10:33

It's accessible via the db

cch118:10:58

OK. But then why require it for queries? It seems inconsistent.

favila18:10:00

The distinction is that queries MUST be evaluated somewhere, conn is where to evaluate it

favila18:10:13

it is not input to the query

favila18:10:32

You can have a query that has no inputs or multiple dbs as input, but it still needs to run somewhere

favila18:10:36

the connection is where it runs

cch118:10:58

Right. But pulls don’t need to run anywhere?

favila19:10:02

with the other apis, the input and where it runs are the same.

favila19:10:40

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

favila19:10:04

queries have arbitrary inputs (including no input), so you need to be explicit

cch119:10:50

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?

cch119:10:18

In contrast, pull must take a db arg, from which a conn can be determined.

favila19:10:30

yes exactly

favila19:10:09

Really, its that query is an RPC. the database inputs (if any) are sent "by-reference" to the conn

favila19:10:46

pull and datoms are more like reads

favila19:10:22

This makes more sense if you compare with the peer api. Queries run locally in the peer api

favila19:10:41

there is no connection object there

cch119:10:50

Yes. And that is how I got confused. I assumed it was a question of a dependency on datalog.

favila19:10:20

Think of it in terms of whether you need to access storage vs transactor

favila19:10:41

db is read-only access to storage. In client api, it's routed to the peer server

favila19:10:52

in peer api, it's a direct connection to storage

favila19:10:19

conn is for transactor access. in peer, that's only for tx-log and d/transact

favila19:10:45

in client, these are all routed through the peer server too, which also provides query

favila19:10:38

that's an attempt at an analogy between peer and client access patterns

cch119:10:27

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?

cch119:10:13

(client/db $connection) => {:database-id "datomic:", :t 1009, :next-t 1013}

favila19:10:13

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

favila19:10:37

the connection string is right there?

cch119:10:45

That’s storage, not the peer.

favila19:10:09

is this a plain map?

cch119:10:14

checking…

favila19:10:43

then there must be a global which maps storages to peer servers

cch119:10:54

That is surprising.

favila19:10:18

makes sense given the peer api

favila19:10:35

they were probably trying to be as close to that as possible

favila19:10:48

with query, it is impossible

cch119:10:00

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.

favila19:10:41

from which input argument would you infer the peer endpoint?

favila19:10:56

queries have no necessary connection to storages

cch119:10:18

yes, of course. I again forgot about the “no dbs” case.

favila19:10:49

can you query different peer servers?

favila19:10:56

(in the same query)

favila19:10:13

Seems possible to me

favila19:10:49

what I mean is, dbs come from connections from different endpoints, mixed together in the same query

cch119:10:01

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

favila19:10:04

as long as the peer server can access that storage it should be possible for it to execute the query

cch119:10:13

I suppose so.

cch119:10:52

On a similar note, I found it interesting that pull can’t work on an arbitrary set of datoms -like query can.

cch119:10:42

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)

favila19:10:02

pull only works on dbs. same in peer api

favila19:10:50

you need to supply something that admits of d/datoms-like calls to it. (whatever the internal interface is)

cch118:10:29

And, another question: is there a spec or documentation somewhere for the :tx-data key returned from a transaction?

favila19:10:58

It's a vector of raw datoms, same as you would get from d/datoms

cch119:10:30

Presumably in the order provided as input, modulo the obfuscation that entity map form introduces.

favila19:10:16

order is arbitrary, it's all set-wise

favila19:10:55

tx-data tells you what actually was added and retracted, vs what you asked to happen