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

feat: Barrage Refactor Read/Write Chunk Factories #6065

Open
wants to merge 109 commits into
base: main
Choose a base branch
from

Conversation

nbauernfeind
Copy link
Member

@nbauernfeind nbauernfeind commented Sep 13, 2024

This is an overhaul of type mapping from arrow to deephaven columns. We can now coerce from many kinds of types, enabling widening / truncating and conversion between types. For example uint64_t is now mapped to BigInteger by default, but can be explicitly mapped to long.class (may overflow).

To set an explicit mapping set the attribute "deephaven:type" to the canonical name of the class.

Fixes #58 (custom type serialization / deserialization).
Fixes #936 (ColumnConversionModes is being replaced with easy to integrate custom serialization).
Fixes #2984 (refactoring has good interface documentation).
Fixes #3403 (by supporting a variety of mappings, these now must match client wiring).
Fixes #5258 (snapshot/subscribe methods with default w2w options).
Fixes #5453 (support other Timestamp arrow wire encodings).
Fixes #5864 (support for uint64_t).
Fixes #6114 (supports ObjectVector properly).

nightlies: https://github.com/nbauernfeind/deephaven-core/actions/runs/13208235220/

@nbauernfeind nbauernfeind added this to the 0.37.0 milestone Sep 13, 2024
@nbauernfeind nbauernfeind self-assigned this Sep 13, 2024
@nbauernfeind nbauernfeind marked this pull request as draft September 13, 2024 15:08
Copy link
Member

@rcaudy rcaudy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little nervous about the scope, and the willingness to truncate inputs or infer units.

@@ -18,7 +20,56 @@
/**
* Consumes Flight/Barrage streams and transforms them into WritableChunks.
*/
public interface ChunkReader {
public interface ChunkReader<ReadChunkType extends WritableChunk<Values>> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We wondered if you could make the bound looser, e.g. PoolableChunk or SafeCloseable. Looks like maybe not? Should PoolableChunk be a Chunk (it's not right now)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need these to return the Chunks to support usages such as LongChunkReader#transformTo. Since ownership is also being passed, it is best to advertise that they're WritableChunks.

}
}

private static long factorForTimeUnit(final TimeUnit unit) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ryan's placeholder.

final float value = src.get(ii);
dst.set(dstOffset + ii, value == QueryConstants.NULL_FLOAT
? null
: BigInteger.valueOf((long) value));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The long conversion in the middle here is causing us to truncate things inappropriately. I think you need to do a BigDecimal.valueOf followed by a toBigInteger. Same for double. For the Float16, we should be safe.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. I wonder why the random tests never pick a value that hit the early truncation. Maybe my equality tolerance is too loose?

@@ -0,0 +1,74 @@
//
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't get hit in the Java test, but presumably it is fine because we are exercising it with C++ tests on each nightly build?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are explicit unit tests for this; just not in the type-cross sectional use. (FlightMessageRoundTripTest)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran full coverage with Stan's jacoco merge tool, and it is still a zero:
image

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