You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure what the exact reasoning is behind using a Deno specific unsigned value (please enlighten me!), but I'd it's quite limiting. It looks like FoundationDB supports atomic operations for signed values just fine.
Because of the unsignedness restriction, some seemingly simple use cases are impossible:
Imo, a nice solution would be to get rid of Deno.KvU64 altogether and just opaquely swap it out for a (signed) long value internally. Throwing when the value goes out of range.
Another, albeit less nice, solution would be to give the option to use either Deno.KvU64 or a signed variant of it when you set a value.
Thanks!
The text was updated successfully, but these errors were encountered:
Hello again,
I'm not sure what the exact reasoning is behind using a Deno specific unsigned value (please enlighten me!), but I'd it's quite limiting. It looks like FoundationDB supports atomic operations for signed values just fine.
Because of the unsignedness restriction, some seemingly simple use cases are impossible:
This throws with
TypeError: Failed to perform 'sum' mutation on a non-U64 value in the database
.We also cannot subtract from atomic values at all:
RangeError: value must be a positive bigint
Imo, a nice solution would be to get rid of
Deno.KvU64
altogether and just opaquely swap it out for a (signed) long value internally. Throwing when the value goes out of range.Another, albeit less nice, solution would be to give the option to use either Deno.KvU64 or a signed variant of it when you set a value.
Thanks!
The text was updated successfully, but these errors were encountered: