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

[SPARK-46961][SS] Using ProcessorContext to store and retrieve handle #45359

Closed
wants to merge 5 commits into from

Conversation

ericm-db
Copy link
Contributor

@ericm-db ericm-db commented Mar 1, 2024

What changes were proposed in this pull request?

Setting the processorHandle as a part of the statefulProcessor, so that the user doesn't have to explicitly keep track of it, and can instead simply call getStatefulProcessorHandle

Why are the changes needed?

This enhances the usability of the State API

Does this PR introduce any user-facing change?

Yes, this is an API change. This enhances usability of the StatefulProcessorHandle and the TransformWithState operator.

How was this patch tested?

Existing unit tests are sufficient

Was this patch authored or co-authored using generative AI tooling?

No

@@ -53,6 +53,12 @@ private[sql] trait ExecutionErrors extends DataTypeErrorsBase {
e)
}

def stateStoreHandleNotInitialized(): SparkRuntimeException = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we move this to the StateStoreErrors.scala to keep error classes in this area in a common location ?

Copy link
Member

Choose a reason for hiding this comment

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

@ericm-db Could you move it, please.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@MaxGekk we can't move it to StateStoreErrors.scala because we can't use it in sql/api/ where we throw the error

Copy link
Member

Choose a reason for hiding this comment

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

I see. ok.

@ericm-db
Copy link
Contributor Author

ericm-db commented Mar 1, 2024

cc @HeartSaVioR @MaxGekk

@github-actions github-actions bot added the DOCS label Mar 1, 2024
@ericm-db ericm-db requested a review from MaxGekk March 4, 2024 16:55
@MaxGekk
Copy link
Member

MaxGekk commented Mar 4, 2024

All GAs passed.

+1, LGTM. Merging to master.
Thank you, @ericm-db and @anishshri-db for review.

@MaxGekk MaxGekk closed this in 6b5917b Mar 4, 2024
ericm-db added a commit to ericm-db/spark that referenced this pull request Mar 5, 2024
Setting the processorHandle as a part of the statefulProcessor, so that the user doesn't have to explicitly keep track of it, and can instead simply call `getStatefulProcessorHandle`

This enhances the usability of the State API

Yes, this is an API change. This enhances usability of the StatefulProcessorHandle and the TransformWithState operator.

Existing unit tests are sufficient

No

Closes apache#45359 from ericm-db/handle-context.

Authored-by: Eric Marnadi <eric.marnadi@databricks.com>
Signed-off-by: Max Gekk <max.gekk@gmail.com>
jpcorreia99 pushed a commit to jpcorreia99/spark that referenced this pull request Mar 12, 2024
### What changes were proposed in this pull request?

Setting the processorHandle as a part of the statefulProcessor, so that the user doesn't have to explicitly keep track of it, and can instead simply call `getStatefulProcessorHandle`

### Why are the changes needed?

This enhances the usability of the State API

### Does this PR introduce _any_ user-facing change?

Yes, this is an API change. This enhances usability of the StatefulProcessorHandle and the TransformWithState operator.

### How was this patch tested?

Existing unit tests are sufficient

### Was this patch authored or co-authored using generative AI tooling?

No

Closes apache#45359 from ericm-db/handle-context.

Authored-by: Eric Marnadi <eric.marnadi@databricks.com>
Signed-off-by: Max Gekk <max.gekk@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants