Fork me on GitHub
#xtdb
<
2023-07-14
>
Jorin09:07:36

Hi there, it's been a while since I looked into Crux, ahm XTDB and I love how things are going! Looking forward to trying out V2 some day soon πŸ™‚ I had two questions coming up which I currently cannot find an answer for: 1. I love that the event log is accessible via "listen". It simplifies building lots of features in a decoupled and robust manner. But what are the guarantees around "listen"? Is it at least once delivery? Do you receive the whole log or only from the moment you start listening on? And does anything around this change with XTv2? 2. Evict allows you to delete data for regulatory use cases and so on. But what if you messed up and a bug generated way too many documents or worse, it generated a ton of changes for the same document. How do you clean up the mess? Do you have to go into the underlying storage layer to do this? And does this work any differently for XTv2?

refset10:07:02

Hey @U8ZN5EHGU, hope all is well! Thanks for the kind words ☺️ > Is it at least once delivery? Assuming the node isn't restarted it should be exactly once. > Do you receive the whole log or only from the moment you start listening on? Only from the moment you start listening. We have talked internally about somehow combining open-tx-log and listen as a single API, but not made any real steps towards it. > And does anything around this change with XTv2? We haven't built an equivalent API yet. In SQL land we may implement something like LISTEN / NOTIFY around the built-in log table - or we could even look at upcoming standards https://www.confluent.io/en-gb/events/current-2022/sql-extensions-to-support-streaming-data/. Whatever we end up doing, we'll definitely also ensure parity via Datalog. > But what if you messed up and a bug generated way too many documents or worse, it generated a ton of changes for the same document. How do you clean up the mess? Presumably the real impact/concern is about the cost of handling this data ~forever after? If it's really too expensive, then the best thing to do is to decant the data into a fresh XT instance with all the erroneous data filtered data. > does this work any differently for XTv2? The model is more or less the same, but v2 will make it much less expensive to keep the erroneous data around ~forever, so hopefully you can avoid ever thinking about decanting and be satisfied with a :delete

Jorin12:07:35

Thanks Jeremy for the detailed answer! All is well and I have a new chapter coming up in my professional life which I am definitely looking into XT for πŸ™‚ I must admit I forgot about open-tx-log. Together these two functions are definitely enough to build reliable log followers. Looking forward to seeing how the V2 version will look like! You are right, that with a bitemporal system the main concern of having excess data in the log is cost. It is much less scary than I am used to from other systems. And great to hear that this is even less of a concern with v2!

refset02:07:46

Awesome. Looking forward to hearing what you're up to 😁