INCR and DECR command with unsigned value

[aleksraiden]

Search before asking

• I had searched in the issues and found no similar issues.

Motivation

Traditionally, KVrocks like Redis, use signed Int64/Float64 for counter commands (INCR/DECR and HINCR/HDECR). But in extra case, we need more data, a full 64 bit number (unsigned).

Solution

Could we add a command-flag to create only signed value for this commands.

A little bit more, maybe a good idea to add other flag for increment/decrement ONLY.

Why? In my case, we use HSET with incremented fields as a central repository for global counters. like tradeId. So, we need always monotonic counter, without possibility of modify element in decrement.

And we need real Int64 unsigned value, because in hi-load HFT-system and hundred of assets, this counter must be presents over all period (need for regulatory requirements, an least 5 years all data must be stored and availability)

Are you willing to submit a PR?

• I'm willing to submit a PR!

[uds5501]

Will pick this up

[torwig]

@uds5501 Assigned. Thank you!

[git-hulk]

@aleksraiden @torwig I have a bit of doubt about this improvement. If the 63-bit is not enough for recording id, then the 64-bit should be also helpless. It makes sense to extend the 64-bit integer to 128-bit, but not from 63 to 64 from my perspective.

[aleksraiden]

As I think, no. So, this is a two different points:

1. Extend a value up to 128 bit. But in this way maybe we have a lot of troubles with external system (and need to use string type over a Int64)
2. Add an option to modify INCR (or add new version of it) when we can't change increment to decr in same key. We need an only totally always increment or decrement, but nobody cant do about INCR test 1 and then DECR test 1.

[uds5501]

Add an option to modify INCR (or add new version of it) when we can't change increment to decr in same key. We need an only totally always increment or decrement, but nobody cant do about INCR test 1 and then DECR test 1.

@aleksraiden @git-hulk I am a bit lost here, what kind of behaviour is expected? Why shouldn't we be able to both INCR and DECR a key? Why have a monotonic function?

[git-hulk]

Add an option to modify INCR (or add new version of it) when we can't change increment to decr in same key. We need an only totally always increment or decrement, but nobody cant do about INCR test 1 and then DECR test 1.

@aleksraiden @uds5501 I don't think we should offer this ability in a generalized database and should control this on the user's side.

Extend a value up to 128 bit. But in this way maybe we have a lot of troubles with external system (and need to use string type over a Int64)

That's right, my doubt is why 64-bit can help compared to 63-bit. My opinion is 64-bit shouldn't help if 63-bit is not enough for your scenario.