3 ms·
The writes are not tunneled somehow through this algorithm. You still use the database like your normally would do. So the consistency is not affected. Also th
by eventreduce 6y ago
The writes are not tunneled somehow through this algorithm. You still use the database like your normally would do. So the consistency is not affected.
Also this is an open source project, not something I want to sell you. Feel free to make a PR/issue with any open topics that are not mentioned in the docs.
- ComodoHacker 6y ago>The writes are not tunneled somehow through this algorithm Then I fail to understand how it works. How Event-Reduce becomes aware of these "write events"? >this is an open source project, not something I want to sell you You made it open source so others can use it, right? They better be making an informed decision whether your solution suits their needs.
- eventreduce 6y agoYou have to provide the events by yourself. See EventReduce as a simple function that can do oldResults+Event=newResults. And yes, you should always do testings before you use open source stuff. There is no warranty use it on your own risk.
- ComodoHacker 6y agoOK, so you don't "tunnel writes through" EventReduce, you "tee" them to EventReduce. Anyway, to maintain consistency, you have to limit yourself to one process of your app. No sharding, load-balancing etc. This is significant limitation, and it's not obvious. I encourage you to mention it in README.md.
- eventreduce 6y agoI encourage you to read the readme and check out the demo. EventReduce is nothing magically drills out your database and affects the consistency of your write-accesses. It is a simple algorithm that is implemented as a function with two inputs and one output.
- EdwardDiego 6y ago> How Event-Reduce becomes aware of these "write events"? Some DBs expose an event stream, for example, PG: https://www.postgresql.org/docs/current/logicaldecoding-explanation.html https://www.postgresql.org/docs/current/logicaldecoding-expl...