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

refactor!: Extract factory interface for ChunkInputStreamGenerators #5811

Merged
merged 5 commits into from
Aug 2, 2024

Conversation

niloc132
Copy link
Member

Rather than relying on a static method to create CISG instances, extracts a factory so that the JS client can provide its own implementation of how CISG instances should be built.

Also cleans up ChunkReader/ChunkInputStreamGenerator split a bit more, since for now JS can only use the former.

BREAKING CHANGES: Removes ChunkInputStreamGenerator.makeInputStreamGenerator, use the default factory instance instead.
Partial #188

@niloc132 niloc132 added this to the 0.36.0 milestone Jul 19, 2024
@niloc132
Copy link
Member Author

I'm not sure if I would actually qualify this as a "breaking change", will leave it up to reviewers.


public class VarListChunkInputStreamGenerator<T> extends BaseChunkInputStreamGenerator<ObjectChunk<T, Values>> {
private static final String DEBUG_NAME = "VarListChunkInputStreamGenerator";

private final Factory factory;
Copy link
Member Author

Choose a reason for hiding this comment

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

Future follow-up:
I'd sort of like to find a pattern where this isn't retained into a field, but just used in the constructor, since in theory we only need to create the input stream generator - like creating innerGenerator etc up front, but not sure about that.

Also might want to move the factory instance to the last param rather than the first, like the ChunkReader apis.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe we can save a functor to go from innerChunk -> innerGenerator instead?

Comment on lines +42 to +45
final ChunkType chunkType,
final Class<T> type,
final Class<?> componentType,
final Chunk<Values> chunk,
Copy link
Member Author

Choose a reason for hiding this comment

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

Why don't we read the chunk type from the chunk?

Future follow-up: use the ChunkReader.TypeInfo here instead of type/componentType/chunkType (and possible future need for arrow Field)?

Copy link
Member

Choose a reason for hiding this comment

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

TypeInfo is good if it has the arrow field, too. If Chunk has a getChunkType.. oops; feel free to use it instead.

@niloc132 niloc132 requested a review from rcaudy July 19, 2024 20:47
Comment on lines +42 to +45
final ChunkType chunkType,
final Class<T> type,
final Class<?> componentType,
final Chunk<Values> chunk,
Copy link
Member

Choose a reason for hiding this comment

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

TypeInfo is good if it has the arrow field, too. If Chunk has a getChunkType.. oops; feel free to use it instead.


public class VarListChunkInputStreamGenerator<T> extends BaseChunkInputStreamGenerator<ObjectChunk<T, Values>> {
private static final String DEBUG_NAME = "VarListChunkInputStreamGenerator";

private final Factory factory;
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we can save a functor to go from innerChunk -> innerGenerator instead?

@niloc132 niloc132 merged commit 974f9fb into deephaven:main Aug 2, 2024
16 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Aug 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants