Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In addition to single-key asynchronous watches, there are also versionstamped ops (for maintaining your own, sophisticated log in a layer) and configurable key range transaction logging (but see the caveats in my other post on the topic).

I'm not sure it has every feature it will ever need in this area, but it's a pretty good starting point for building "reactive" stuff.



Your response is both very exciting and slightly intimidating! Would love to see a “NewSQL” and/or event store built on top of FDB tech. Would the key ranges and versioned ops be capable of providing/emulating a performant “atomic broadcast” similar to that in Kafka?


Does the trigger execute in scope of triggering transaction with the same isolation level?


Versionstamped operations and transaction logging are fully transactional. Watches are asynchronous: they are used to optimize a polling loop that would "work" without them.


Would versionstamped operations fit for the log abstraction modeling question I've asked about here on the forums?

https://forums.foundationdb.org/t/log-abstraction-on-foundat...


Yes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: