Clarify Gremlin.Net type limitations with reproductions - #3683
spmallette wants to merge 2 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3683 +/- ##
============================================
+ Coverage 76.35% 80.05% +3.69%
============================================
Files 1012 32 -980
Lines 60341 6913 -53428
Branches 7075 0 -7075
============================================
- Hits 46076 5534 -40542
+ Misses 11548 1053 -10495
+ Partials 2717 326 -2391 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Sharpen the Gremlin.Net Limitations section so each type-range limitation states its true trigger and the concrete behavior a user hits when the server returns an out-of-range value. The DateTimeOffset entry notes that the +/-14:00 offset bound, not merely an extreme year, is the common trigger, and that the DateTimeOffset constructor rejects the value so Gremlin.Net raises an ArgumentOutOfRangeException while reading the result. The Duration and BigDecimal entries name the OverflowException raised when a value exceeds the TimeSpan range or the decimal precision of 28-29 digits. The null Map key entry states that such a result raises an IOException. The non-BMP character entry now states the real behavior: the four-byte Char is decoded into a surrogate pair of which only the leading surrogate is returned, so the character is silently corrupted without an error. Assisted-by: Kiro:claude-opus-4.8
7cde46e to
d0fbc28
Compare
| so offset date-time values at those boundaries will fail to deserialize. | ||
| * Gremlin's `Duration` type has a much larger range than C#'s `TimeSpan`, so extreme duration values (such as | ||
| `Duration.FOREVER`) that exceed `TimeSpan.MaxValue` or `TimeSpan.MinValue` will fail to deserialize. | ||
| * C#'s `DateTimeOffset` accepts offsets only in the range `-14:00` to `+14:00` and years from 1 to 9999, while |
There was a problem hiding this comment.
Both the DateTime and Duration entries here cover the range limitation accurately, but there is also a precision limitation when converting from gremlin types to dotnet. Gremlin uses nanosecond precision for both types, while dotnet is limited to 100ns "ticks". These types are truncated upon deserialization (00.123456789s -> 00.1234567s)
There was a problem hiding this comment.
There is one other weird case with DateTimeOffset in .Net, the offset is specified in whole minutes, while Java and GraphBinary specify the offset as a number of seconds. It appears that datetimes with a sub-minute precision offset currently throw an ArgumentException when attempting to deserialize in .Net. We should document this for now, it's probably worth a JIRA to intercept this and truncate the seconds portion of the offset.
|
VOTE +1 pending comment resolution |
The Gremlin.Net limitations section now notes two further deserialization behaviors for temporal types. Both DateTimeOffset and Duration silently truncate fractional seconds finer than the .NET 100-nanosecond tick, since Gremlin represents time with nanosecond precision. A DateTimeOffset whose UTC offset carries a sub-minute component also cannot be represented, because .NET expresses the offset in whole minutes while Java and GraphBinary express it in seconds, and Gremlin.Net raises an ArgumentException in that case. Assisted-by: Kiro:claude-opus-4.8
Sharpen the Gremlin.Net Limitations section so each type-range limitation states its true trigger and can be reproduced. The DateTimeOffset entry now notes that the +/-14:00 offset bound is the common trigger, not just the year range. The null Map key entry explains that group()/groupCount() over a missing property drops the element rather than producing a null key, so a null key must be injected explicitly. The Duration and non-BMP char entries clarify that only out-of-range values are affected. A short csharp example reproduces the offset, high-precision decimal, and null-key cases against a modern-graph server.