91–100 of 143 posts
Earlier quoted context omitted.
Not a month goes by where I don’t remember it at least once and realize that I still miss it. This seems more like Redis though
Why don't you run the open source version?
One example among many:
https://github.com/DiceDB/dice/blob/0e241a9ca253f17b4d364cdf... defines func ExpandID, which reads from cycleMap without locking the package-global mutex; and func NextID, which writes to cycleMap under a lock of the package-global mutex. So writes are synchronized, but only between each other, and not with reads, so concurrent calls to ExpandID and NextID would race.
This is all fine as a hobby project or whatever, but very far from any kind of production-capable system.
Earlier quoted context omitted.
Arpit here. DiceDB is an in-memory database that is also reactive. So, instead of polling the database for changes, the database pushes the resultset if you subscribe to it. We have a similar set of commands as Redis, but are not Redis-compliant.
This is a lot clearer than any information I found anywhere else. There wasn't any room on your website, README, or docs for this summary?
There are _so many_ bugs in this code. One example among many: https://github.com/DiceDB/dice/blob/0e241a9ca253f17b4d364cdf... defines func ExpandID, which reads from cycleMap without locking the package-global mutex; and func NextID, which writes to cycleMap under a lock of the package-global mutex. So writes are synchronized, but only between each other, and not with reads, so concurrent calls to ExpandID and NextI…
Why would I use this over keyspace notifications in redis?
But certainly you could build something to handle these and most other needs in this realm with mostly just redis, using streams for what needs to be more robust, in tandem with pub/sub, keyspace notifs, etc. in the areas they are suited to.