Which line(s) are you looking at for this?

If I've understood you correctly: once a document's been evicted, we no longer have access to the original eid - the only thing we can give you is its hash

Sorry, that was indeed somewhat ambiguous. I am referring to tx-ops for a secondary index. On put it is the value of the eid, while on evict it is the hash. While it’s not the end of the world, it means that secondary indices are then responsible of maintaining an index using the hash (which maybe I should have always been doing)

Hmm, so looking at these lines: https://github.com/xtdb/xtdb/blob/e2f51ed99fc2716faa8ad254c0b18166c937b134/core/src/xtdb/tx/conform.clj#L41-L44 we see that the put op transformation returns :eid (:xt/id doc) and :doc-id doc-id (c/hash-doc doc) whereas the evict transform (further down that ns) sets the hashed eid on :eid ....so I agree it seems a little confusing. I'm not sure of the history there or implications

delete the golden stores? and any indexes

That's correct, you must .stop the node and delete the directories manually/programmatically. There is no provided API to do this. In tests we use this with-tmp-dir macro extensively https://github.com/xtdb/xtdb/blob/20a2632a18a36dae2e915ab032307ce0c5b3e150/test/src/xtdb/fixtures.clj#L16-L26

thanks

Ah, stopping the node is what I was missing, I was just dropping the tables duh!

also, could I just flip the database and use postgres for persistance (like I know, xtdb stores documents, so I am not getting relational tables from this, but I have infra in place and don't really want to add/deal with rocksdb/kafka. (so... to rephrase a bit I know I can use postgres as transaction/doc storage, but how performant/trouble-free is it)

Hi 🙂 > Temporality aside (its not much, I think I can handle within postgres) Is the temporality in your use-case something you expect to grow much more complex in future? How many tables are you adding valid-from/to columns to? Are all the tables treated as append-only already? For the most general cases I expect the average developer will (still) have an easier time working with Postgres than XT for the simple reason that there is a huge wealth of features, libraries, & resources available when using Postgres, which are battle-hardened and ready to help you out in nearly all possible scenarios. The main exceptions to this are when you have a problem or use-case that really demands the Datalog/graph & bitemporal features on offer with XT, as Postgres will struggle to help you there at any significant scale. That said, if you are comfortable with the idea of navigating the tradeoffs as they come, then I'd argue that you can achieve almost anything in XT with a little extra code and modelling forethought. Which is particularly true when used with Clojure. > I know I can use postgres as transaction/doc storage, but how performant/trouble-free is it I'll leave it to others to chime in with anecdata here, but it certainly shouldn't be much slower / worse. Incidentally an issue was raised very recently to reduce the transaction latency for JDBC backends https://github.com/xtdb/xtdb/issues/1623

For me datalog is a big deal when writing queries, I find modeling in tables a bit awkward. Datalog + pull + pathom is all I need for my back-end to resolve complicated and flexible queries from a quite dynamic front-end. Very happy with xtdb.

This line makes me confused. do you want the xtdb index to communicate with the golden stores over the network or locally?

Over the network.

So, you'd have your tx log/doc store available centrally, then your device local indexes which you query will be all be full replicas. Is that what you want? It's how xtdb always works :)

I'd like it to be peer-to-peer.

So there won't be a write-master.

There may be conflicts.

That's ok; I can deal with that.

e.g., the application always writes to its local database because the network isn't always available.

Xtdb would leave those details down to the doc store/tx logs themselves, and I don't think there is one written that supports that use case well. You'd probably have to write an implementation for e.g. couchdb

or maybe you could try jdbc and rqlite if you're brave

actually I think all the sqlite distributed databases assume a leader too

OK; I was afraid of that. But thanks much for the information.!

I’ve been doing something similar using a Yjs document for application state. Works well for real-time collaboration and for merging in remote changes

Thanks @UE72GJS7J. I'm on the JVM for now. Sadly, it seems all the cool kids doing p2p these days use Javascript, Go, or Rust (in about that order).

I’m using ClojureScript on the server for that reason, and just to get something usable out the door until I can think better about different approaches to replicated data

I did experiment briefly with encoding a Hybrid Logical Clock into XT's valid-time as a zero-conflict / non-destructive last-writer-wins synchronisation mechanism but didn't get as far as working prototype (though I see no reason why it wouldn't work great) https://github.com/xtdb/xtdb/issues/895#issuecomment-636041476

I was quite inspired to attempt it after watching this talk about building an offline-first app https://www.youtube.com/watch?v=DEcwa68f-jY

@U899JBRPF Super cool you're thinking about this! This idea came up in a discussion recently, and at some point I came around to the idea that you wouldn't want to do it with valid-time, but rather the transaction time. This seems to make more sense semantically (valid-time seems more domain focused IIUC; like when in the real world did this fact become true), whereas transaction time is about when that fact was asserted, and it would seem to be the latter that you would want to do this with. However, I could also imagine based on the architecture that doing this with transaction time might be more challenging. Curious about your thoughts on this.

Hey @U05100J3V nice to see you here 🙂 (not sure if you remember, but we did swap emails like 5 years ago!) > based on the architecture that doing this with transaction time might be more challenging Yes indeed, it would be problematic. XT's transaction time is assumed to be immutable & monotonic, and is what underpins all the potential for horizontal read scaling. With valid time though, XT really doesn't care how you apply it's semantics to your use-case. The only "baked-in" assumption is a total ordering of 64-bit Longs.

I can kind of imagine "vector clock time" being some middling 3rd time dimension in between the other two, so that valid time is still available for more traditional usage, but it's out of scope of our current roadmap for now. In principle though, the upcoming temporal indexes could scale to additional dimensions (currently it's only working with 6)

@U899JBRPF I do remember! It's good to chat with you again 🙂

Thanks for sharing your thoughts on this.