That is, there's no way to query without any validity constraints. I can only query in a snapshot of time, or look at a full history of one document.

I guess you could touch the main entity as well, just re-put it without changes... but that feels a little awkward

> If I wanted to know the history of phone numbers for a person, I would have to iterate through the history of every phone number record, right? I think so. > That is, there's no way to query without any validity constraints. I can only query in a snapshot of time, or look at a full history of one document. This is the case for the current incarnation of XT. In the future architecture, 'cross time' will be first-class though 🙂

Something ate your response

Future sounds good enough. At this point we want to shape our data so that we don't paint ourselves in the corner, but we don't need to paint the wall yet, I mean run audit queries yet

We just fetch the entity and then match on it. Of course there's a race condition if something changes it, so it really needs a retry. More robust system would use a separate transaction function that would do the fetch and match

So something like (very hypothetically) this:

[[::xt/match :foo ::xt/not-nil]
 [::xt/put {:xt/id :foo}]]

[[::xt/fn : :foo]
 [::xt/put {:xt/id :foo}]]

We also have a use case where a new value doesn't depend on the old value so we don't really need the entity. Except if it's deleted, when it shouldn't be recreated, undoing the deletion

At this moment all of these are related to users, where deletion means revocation of rights. Users themselves, sessions, etc

Perhaps it's more correct to say that we can do this precisely because we can get the previous versions via time travel. Otherwise we would instead create new entities, and mark the old one as invalid, somehow

Gotcha, thank you both for your answers! In our case, we want to add a field to a doc, however this event may arrive to the system before the target document has been initialized. I'm thinking that since the update event carries the target ID, and since the we're talking about adding a field, it should be fine with having the initialization event be added to the doc through assoc and thus not overwrite any data. My question then has to do with checking whether or not we should append to an existing doc or put/init a new one. I'll definitely try the tx-function, thanks again!

Hi 🙂 if you need HA durability, then you'll want a properly configured (distributed) Postgres/MySQL/etc or Kafka, but maybe RocksDB x3 (for tx-log, doc-store, and index-store) is enough if you can live with the potential for losing writes between backups

Thanks for teh reply. Are there any cases in which you'd recommend s3?

When using psql (as an example). Is the convention to setup two different db's. One for the tx log and one for the document store?

I think if you're already using Postgres then S3 probably isn't offering much advantage as the doc-store

S3 is definitely a good choice as a checkpoint store

Thanks