After updating xtdb version, I got a more meaningful error message with the old index.

; Execution error (IndexVersionOutOfSyncException) at xtdb.kv.index-store/check-and-store-index-version (index_store.clj:357).
; Index version on disk: 18 does not match index version of code: 22

Thinking now that if we are updating multiple nodes with old indices and we upgrade xtdb version, we might run into a situation where different versions try to access db with different index versions.

hey @U0267SNCPEY 👋 nodes < 1.21.0 https://github.com/xtdb/xtdb/issues/1888 to read transaction logs with transactions submitted after 1.21.0 due to the new ability for the user to explicitly specify the tx-time of a transaction (for bulk import purposes) - we're investigating what's involved in a fix, but in the meantime I'd recommend upgrading the nodes (as you have)

Ah, ok! Thx!

So I could assume that after this update we shouldn't run into similar incompatibilities or they would labeled as breaking changes?

> After updating xtdb version, I got a more meaningful error message with the old index This is an 'index version bump' - we put these through every now and again when we want to upgrade the index structure - most recently a handful of indexing performance improvements. In this case, you'll want to let a new version of XT re-index from the tx-log in the background, and create a checkpoint that other nodes can then use

> Thinking now that if we are updating multiple nodes with old indices and we upgrade xtdb version, we might run into a situation where different versions try to access db with different index versions. each node has its own index, so you shouldn't ever get a case where a node reads an incompatible index version - that's what the 'index version' check prevents

> So I could assume that after this update we shouldn't run into similar incompatibilities or they would labeled as breaking changes? yep, absolutely. tbh this is the only tx-log format change we've put in in my ~3 years in XTDB - it's not something we do on a regular basis, for this very reason 🙂

> each node has its own index, so you shouldn't ever get a case where a node reads an incompatible index version - that's what the 'index version' check prevents So, it seems that my case simply reduces to a case where I couldn't sync my local indices as my local index had too old version and the remote db had been updated with newer XTDB version 🙂

fwiw we're looking into the possibility of a non-breaking patch release in the 1.20.x line that users could upgrade to that then would be able to handle >=1.21.0 transactions if that would be useful

It would allow first upgrading all nodes to 1.20.X to be able to read the logs, and then to 1.21.0 so that at no point there would be nodes writing transactions while nodes that cannot read them are still online

But in our case, that's no longer… needed

More the reason to have a staging environment that's identical to the real one, including having multiple nodes

Though I suppose it's a bit tricky to catch even then. You'd need the new nodes to insert new transactions in the middle of the upgrade. Or even exactly the right kind of transactions?

First attempt suggests no

you can if they have different valid time ranges - but if they have both the same valid-time range and tx-time they'll cancel each other out

but yeah, more generally you can't have a zero-width valid-time range in XTDB - it's inclusive-start exclusive-end

ah thanks for the insight

made it work!

[#:xtdb.api{:content-hash #xtdb/id "0000000000000000000000000000000000000000"
            :doc          nil
            :tx-id        2
            :tx-time      #inst "2023-01-25T18:06:23.447-00:00"
            :valid-time   #inst "2023-01-25T18:06:23.448-00:00"}
 #:xtdb.api{:content-hash #xtdb/id "c628864629963b3311fadad544d1d1071a5edc05"
            :doc          {:widget/created-at #inst "2023-01-25T18:06:23.418-00:00"
                           :widget/created-by #:nexus.user{:id #uuid "00000000-0000-0000-0000-000000000001"}
                           :widget/deleted-at #inst "2023-01-25T18:06:23.447-00:00"
                           :widget/deleted-by #:nexus.user{:id #uuid "00000000-0000-0000-0000-000000000001"}
                           :widget/id         #uuid "0185ea1c-06ba-bd41-af80-b84d143e1257"
                           :widget/label      "Label 3"
                           :xt/id                   #:widget{:id #uuid "0185ea1c-06ba-bd41-af80-b84d143e1257"}}
            :tx-id        2
            :tx-time      #inst "2023-01-25T18:06:23.447-00:00"
            :valid-time   #inst "2023-01-25T18:06:23.447-00:00"}
 #:xtdb.api{:content-hash #xtdb/id "a25ca7c8f2a07af6aaf18019d7312833f9feb453"
            :doc          {:widget/created-at #inst "2023-01-25T18:06:23.418-00:00"
                           :widget/created-by #:nexus.user{:id #uuid "00000000-0000-0000-0000-000000000001"}
                           :widget/id         #uuid "0185ea1c-06ba-bd41-af80-b84d143e1257"
                           :widget/label      "Label 3"
                           :xt/id                   #:widget{:id #uuid "0185ea1c-06ba-bd41-af80-b84d143e1257"}}
            :tx-id        1
            :tx-time      #inst "2023-01-25T18:06:23.418-00:00"
            :valid-time   #inst "2023-01-25T18:06:23.418-00:00"}]

hey @U04HFRYJTNW 👋 we don't tend to describe ourselves as a time-series database - this tends to bring a few expectations that we don't aim to cover, e.g. windowing, retention etc. graph: more so - we're a document database which you can query using a graph-like query language, interpreting the values in the documents as potential edges.

it's not a true 'property graph' model - i.e. modelled as distinct vertices and edges - if, for example, you want to add properties to your edges, we recommend that you make another document for the edge with additional attributes, referencing the vertex documents - but we think it covers enough of the benefits with a simpler model 🙂

thank you @U050V1N74

I saw this comparison a few months back that might add some clarity on the 'time series' aspect https://www.pgcon.org/2019/schedule/track/Applications/1336.en.html

Though my experience is pretty limited, I'd say that time-series is more about stocks, or even only about HFT than finance, while temporal is applicable more generally in finance, exactly due to audits and historic views. But I digress.