-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-28199][SS] Move Trigger implementations to Triggers.scala and avoid exposing these to the end users #24996
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
Changes from 3 commits
20059fa
2acc53a
bc5a3fc
12655f0
da6fa51
027e69c
f42e3b5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -17,8 +17,13 @@ | |
|
|
||
| package org.apache.spark.sql.execution.streaming | ||
|
|
||
| import java.util.concurrent.TimeUnit | ||
|
|
||
| import scala.concurrent.duration.Duration | ||
|
|
||
| import org.apache.spark.annotation.{Evolving, Experimental} | ||
| import org.apache.spark.sql.streaming.Trigger | ||
| import org.apache.spark.unsafe.types.CalendarInterval | ||
|
|
||
| /** | ||
| * A [[Trigger]] that processes only one batch of data in a streaming query then terminates | ||
|
|
@@ -27,3 +32,34 @@ import org.apache.spark.sql.streaming.Trigger | |
| @Experimental | ||
| @Evolving | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shall we remove the annotations? it's
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh right. These classes are now not intended to expose so should remove annotations. Thanks for finding it out!
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well... in reality that was done in #25200. Let's make sure we check the latest code (not the code diff) while doing post-hoc review after long delay.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, sure. Thanks :D. |
||
| case object OneTimeTrigger extends Trigger | ||
|
|
||
| /** | ||
| * A [[Trigger]] that runs a query periodically based on the processing time. If `interval` is 0, | ||
| * the query will run as fast as possible. | ||
| */ | ||
| @Evolving | ||
| private[sql] case class ProcessingTimeTrigger(intervalMs: Long) extends Trigger { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you put this into another file like
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I moved this as @srowen's suggestion (#24996 (comment)) as OneTimeTrigger is there without its own file. I'm still not sure, but if the intention of deprecation is hiding implementations to end users, actually I'd also like to move ContinuousTrigger to Triggers.scala, as they can be controlled together. If we change the mind to have file per implementation, Triggers.scala would be better to be renamed as OneTimeTrigger.scala too.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ya.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We might need to keep original class as we haven't deprecated it yet, and to allow end users to only create Trigger implementations as The change may look like below commit: IMHO this could be considered as another issue as more deprecations are happening. WDYT?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ur, moving looks okay, but the new deprecation of Please make another PR for the deprecation of If the PR has multiple themes unexpectedly, we cannot merge it.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My suggestion is we follow the comment above by moving
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry I guess I mixed up. My bad, not moving OneTimeTrigger but moving ContinuousTrigger. Let me enumerate necessary changes from what I understand:
I guess both moving and deprecating make the changeset looking verbose, but I guess even in major release we may not want to remove public classes which haven't been deprecated. I guess my commit (HeartSaVioR@f8488cf) mentioned above already covered it, so please take a look at the commit. If we are OK to go or would like to continue reviewing under the commit, I'll add the commit to the PR.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops I misspoke, I mean "move the implementations to Triggers.scala".
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah either is fine for me too. If we would like to have simpler one, skipping deprecation would work. If we would like to have safer one (possibly user facing API), deprecation would work. I'd like to ask the decision for committers/PMC members, as it seems like related to some policy on the project.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To move this forward, I suggest we just move the class and skip deprecation. A note in the Spark 3.0 migration guide about streaming would be good, as we're removing a deprecated class anyway. |
||
| require(intervalMs >= 0, "the interval of trigger should not be negative") | ||
| } | ||
|
|
||
| private[sql] object ProcessingTimeTrigger { | ||
srowen marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| def apply(interval: String): ProcessingTimeTrigger = { | ||
| val cal = CalendarInterval.fromCaseInsensitiveString(interval) | ||
| if (cal.months > 0) { | ||
| throw new IllegalArgumentException(s"Doesn't support month or year interval: $interval") | ||
| } | ||
| new ProcessingTimeTrigger(TimeUnit.MICROSECONDS.toMillis(cal.microseconds)) | ||
| } | ||
|
|
||
| def apply(interval: Duration): ProcessingTimeTrigger = { | ||
| ProcessingTimeTrigger(interval.toMillis) | ||
| } | ||
|
|
||
| def create(interval: String): ProcessingTimeTrigger = { | ||
| apply(interval) | ||
| } | ||
|
|
||
| def create(interval: Long, unit: TimeUnit): ProcessingTimeTrigger = { | ||
| ProcessingTimeTrigger(unit.toMillis(interval)) | ||
| } | ||
| } | ||
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rename the variable together.
processingTime->processingTimeTrigger.private val intervalMs = processingTime.intervalMs->private val intervalMs = processingTimeTrigger.intervalMs