Fork me on GitHub
#datomic
<
2020-06-24
>
Lone Ranger15:06:00

ok this is a really odd question but ... apparently the storage service they want me to use has a READ port and a WRITE port. I've never seen this before. I'm curious if anyone has any thoughts on how this might be accomplished

favila15:06:50

By “WRITE” do you mean “READ+WRITE”?

favila15:06:04

peers only need read; transactor needs read+write

favila15:06:11

what kind of storage is this?

Lone Ranger15:06:05

correct on the READ+WRITE

Lone Ranger15:06:13

mariadb on something called a galera cluster

Lone Ranger15:06:49

does that just mean I pass the read string to the peers?

Lone Ranger15:06:37

so if I understand this correctly, I pass the "read uri" to the peer. Peer looks up in storage location of transactor. It hands off transactions to transactor and does queries from read? Is that the theory?

favila15:06:59

correct. peers do not write

favila15:06:05

only the transactor writes

Lone Ranger15:06:20

got it. So it won't cause a conflict that I pass in a different string than the transactor suggests on startup?

Lone Ranger15:06:44

just making sure it doesn't do some kind of validation

favila15:06:59

you should understand why there are different ports though

favila15:06:36

is this purely an access-control thing, or do they have different consistency guarantees between them? is the other port a read replica?

Lone Ranger15:06:11

consistency guarantees

Lone Ranger15:06:19

replica, yes. Something about performance

Lone Ranger15:06:46

polite thing to do would be to respect the setup, they said, so wanted to see if I could accomodate

favila16:06:51

what I mean is, could the peer and transactor ever read different things using different ports?

favila16:06:35

transactor does a commit, and then informs peers. The peers need to be able to read what the transactor wrote

Lone Ranger17:06:54

I see. Needs to be strongly consistent?

Lone Ranger17:06:13

I'm not sure -- checking

Lone Ranger17:06:34

"about 1 second" propagation time

Lone Ranger18:06:04

It looks like updates are sent directly from the transactor to the peer

Lone Ranger18:06:20

so as long as it's sending the actual data and not, say, a lookup value then we should be fine

favila18:06:00

I am not a datomic dev, but it seems like at least some things must be lookups sometimes

favila18:06:24

e.g., when a new index is finished

Lone Ranger15:06:02

I'm thinking if I had a peer service that only did upserts and another that only did reads, I could pass a write uri-string to the upsert service and a read uri-string to the query service, while having the transactor sit on the "write node".

Lone Ranger15:06:07

Does that pass a sniff test...?

roland15:06:13

Hello, I saw that there is :reverse option in the index-pull function. Is there also an option to run through the index in reverse order using the datoms function ?