Fork me on GitHub
#datomic
<
2020-06-24
>
unbalanced15: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?

unbalanced15:06:05

correct on the READ+WRITE

unbalanced15:06:13

mariadb on something called a galera cluster

unbalanced15:06:49

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

unbalanced15: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

unbalanced15:06:20

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

unbalanced15: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?

unbalanced15:06:11

consistency guarantees

unbalanced15:06:19

replica, yes. Something about performance

unbalanced15: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

unbalanced17:06:54

I see. Needs to be strongly consistent?

unbalanced17:06:13

I'm not sure -- checking

unbalanced17:06:34

"about 1 second" propagation time

unbalanced18:06:04

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

unbalanced18: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

unbalanced15: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".

unbalanced15: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 ?