Nope. It is unclear whether they would be useful enough or not. But when designing APIs we always need to anticipate future changes.
On Monday, April 18, 2016, Jacek Laskowski <ja...@japila.pl> wrote: > When you say "in the future", do you have any specific timeframe in > mind? You got me curious :) > > Pozdrawiam, > Jacek Laskowski > ---- > https://medium.com/@jaceklaskowski/ > Mastering Apache Spark http://bit.ly/mastering-apache-spark > Follow me at https://twitter.com/jaceklaskowski > > > On Mon, Apr 18, 2016 at 7:44 PM, Reynold Xin <r...@databricks.com > <javascript:;>> wrote: > > The problem with this is that we might introduce event time based > trigger in > > the future, and then it would be more confusing... > > > > > > On Monday, April 18, 2016, Jacek Laskowski <ja...@japila.pl > <javascript:;>> wrote: > >> > >> Hi, > >> > >> While working with structured streaming (aka SparkSQL Streams :)) I > >> thought about adding > >> > >> implicit def toProcessingTime(duration: Duration) = > >> ProcessingTime(duration) > >> > >> What do you think? > >> > >> I think it'd improve the API: > >> > >> .trigger(ProcessingTime(10 seconds)) > >> > >> vs > >> > >> .trigger(10 seconds) > >> > >> (since it's not a release feature I didn't mean to file an issue in > >> JIRA - please guide if needed). > >> > >> Pozdrawiam, > >> Jacek Laskowski > >> ---- > >> https://medium.com/@jaceklaskowski/ > >> Mastering Apache Spark http://bit.ly/mastering-apache-spark > >> Follow me at https://twitter.com/jaceklaskowski > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org <javascript:;> > >> For additional commands, e-mail: dev-h...@spark.apache.org > <javascript:;> > >> > > >
