xtdb

benny 2024-11-12T05:51:22.386069Z

Thanks again for the pleasant office hour chat. I actually prepared a question but didn't remember to ask: In v1 I like xt/listen. Based on my reading v2 appears to not favor in-process, so one would poll the system table xt.txs and roll their own subscription watcher equivalent?

☺️ 1
πŸ‘‹ 1
πŸ‘‹πŸ» 1
jarohen 2024-11-12T09:21:40.941459Z

that's one on our to-do list - but yes, as you say, will require a different solution for the client-server model

jarohen 2024-11-12T09:23:43.463119Z

for now, polling xt.txs is one option, yep, or (if you don't need the results of the XT transaction) we also know of people using XT as a downstream system from their own Kafka log - i.e. one golden-source Kafka topic feeds both a process that submits to XT and whatever other subscriptions you need

benny 2024-11-12T13:09:50.760319Z

In my operational simplified world polling xt.txs seems OK. If I want some additional nicety and want to get on that hypetrain I could try integrating missionary to supervise the downstream consumption and cancel work, if a new tx arrived. But in reality I just need to watch a single table, like normal worker queues on postgres. Thanks!

πŸ™ 1
☺️ 1