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

.Net implementation #16

Open
ra0o0f opened this issue Dec 3, 2016 · 1 comment
Open

.Net implementation #16

ra0o0f opened this issue Dec 3, 2016 · 1 comment

Comments

@ra0o0f
Copy link

ra0o0f commented Dec 3, 2016

Hi

I ported java implementation(tests are passed) to .NET(https://github.com/ra0o0f/velocypack.net).

it supports all c# primitive data types(except decimal) and can also serialize complex objects with a proven performance(using Json.net JsonReader/JsonWriter).

c# decimal is 128-bit data type. compared to floating-point types, but different from Quadruple-precision floating-point which is also 128-bit.
developers use it a lot for financial calculations. which vpack datatype should be used to store decimal since converting to double could loose precision

@jsteemann
Copy link
Contributor

VelocyPack has a Double type for floating-point values, but it is only double precision. That means converting a C# decimal into a VelocyPack Double value would lead to precision loss.

At the moment VelocyPack has no implementation of arbitrary-precision numeric types, though we have reserved some types (0xc8-0xd7) for arbitrary-precision BCDs. As I said we haven't yet implemented them in the C++ driver. That also means BCDs cannot be used on the ArangoDB side, as ArangoDB won't be able to handle BCD types yet.

As a quick workaround you could also use one of the Custom types (e.g. 0xf4) and serialize the bytes of a C# decimal into it. But using a Custom type also has issues: every piece of software that needs to figure out the meaning of this type needs to know how to interpret it. ArangoDB won't be able to figure out what this Custom type means, so its values will not be usable in any calculations etc. inside ArangoDB.

So at the moment the lossy conversion to a VelocyPack double seems to be the most sensible way forward in terms of usability and development effort. Implementing BCDs or other higher precision number types for VelocyPack is on our agenda, but we haven't found time yet to work on this.

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

2 participants