Fork me on GitHub
#xtdb
<
2024-03-14
>
Hukka06:03:05

I tried searching in discuss, here and generally in google, and didn't see anyone commenting about running XTDBv2 on ARM macs. No news is good news, and it works just fine?

jarohen07:03:37

Should do, yep. We don't have the RocksDB/LMDB dependencies of XT1, so there's less to go wrong πŸ™‚

refset08:03:52

Some of the team has been using M1 Macs with v2 in recent months without issues, but generally we're all running archlinux on x86

❀️ 1
Hukka08:03:45

So they are on Asahi, then πŸ˜‰

πŸ˜„ 1
mikejcusack10:03:17

Yay for Arch!

☺️ 1
jarohen10:03:01

heh - yeah, "we use Arch btw" πŸ˜„

😁 2
mikejcusack11:03:08

I've been on an M1 MBP for work, but I've been missing Arch dearly

jarohen11:03:19

I survived on Mac for a couple of weeks at my previous place, gave it a good go, but it's just not Linux - way too much clicking for me.

mikejcusack11:03:41

I hear you on that one

Dallas Surewood23:03:04

I am wondering how we deal with multiple processes changing the same document. We have two tools for this. 1. xt/match 2. xt/await-tx How would I use these to make sure that, for instance, two users editing the same document (like something in a shared app) have both their changes recognized without losing either? The only idea I've had is some kind of queue with retry logic between each transaction, but I'm not sure how to implement it. xt/await-tx doesn't really work by itself because it only waits until the node is up to date. It doesn't tell you if the document you were trying to submit is now stale. I don't think xt/match works either. We could make something that β€’ Tries a transaction with xt/match, fails if the document has changed from the old one β€’ Fetches the new document. β€’ Tries the transaction again But this doesn't get around the problem of the users submitted document being sterile. It seems like the only option is if the user is pushing up differences with something like editscript and then we process the documents that way.

Hukka06:03:46

Indeed, the database part in this is easiest. Harder is figuring out how the changes even could be compatible. The only sure way in general is to accept the first one, whoever is first, and then represent the changes to the second user and let them manually make changes if needed

Hukka06:03:59

And if that retrying is not viable, have locking in place

Dallas Surewood15:03:00

Got it. Just making sure there's not an obvious way to do it with these tools

refset16:03:39

Hey @U042LKM3WCW it's an interesting/hard problem space for sure, and I can only really add that the other key affordance XT offers is transaction functions - but they only really help with avoid excessive retries in the face of ~continual staleness (contention, essentially)