Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider replacing Deno.KvU64 by standard BigInt #104

Open
WilcoKruijer opened this issue Dec 12, 2024 · 0 comments
Open

Consider replacing Deno.KvU64 by standard BigInt #104

WilcoKruijer opened this issue Dec 12, 2024 · 0 comments

Comments

@WilcoKruijer
Copy link

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:

  await db.atomic()
    .set(["a"], 1n)
    .commit();
  await db.atomic()
    .sum(["a"], 2n).commit();

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:

  await db.atomic()
    .set(["a"], new Deno.KvU64(100n));
    .commit();

  await db.atomic()
    .sum(["a"], -3n);
    .commit();

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant