[
https://issues.apache.org/jira/browse/SPARK-32046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203040#comment-17203040
]
Pablo Langa Blanco edited comment on SPARK-32046 at 9/28/20, 4:20 PM:
----------------------------------------------------------------------
I have been looking at the problem and I think I have understood the problem.
What I don't understand is why Jupyter and ZP behave differently.
When a dataframe is cached, the key to the map that stores the cached objects
is a plan. (df1.queryExecution.analyzed.canonicalized). Then, in the second
execution, when you go to check if the dataframe is cached you do the following
check.
{code:java}
df1.queryExecution.analyzed.canonicalized ==
df2.queryExecution.analyzed.canonicalized{code}
In this case, both execution plans are the same so it considers that it has the
Dataframe cached and uses it
It seems a rather strange case in real life to have 2 identical Dataframes, one
cached and one not, have a timestamp and do not want to reuse the cached
Dataframe
was (Author: planga82):
I have been looking at the problem and I think I have understood the problem.
What I don't understand is why Jupyter and ZP behave differently.
When a dataframe is cached, the key to the map that stores the cached objects
is a plan. (df1.queryExecution.analyzed.canonicalized). Then, in the second
execution, when you go to check if the dataframe is cached you do the following
check.
df1.queryExecution.analyzed.canonicalized ==
df2.queryExecution.analyzed.canonicalized
In this case, both execution plans are the same so it considers that it has the
Dataframe cached and uses it
It seems a rather strange case in real life to have 2 identical Dataframes, one
cached and one not, have a timestamp and do not want to reuse the cached
Dataframe
> current_timestamp called in a cache dataframe freezes the time for all future
> calls
> -----------------------------------------------------------------------------------
>
> Key: SPARK-32046
> URL: https://issues.apache.org/jira/browse/SPARK-32046
> Project: Spark
> Issue Type: Bug
> Components: SQL
> Affects Versions: 2.3.0, 2.4.4, 3.0.0
> Reporter: Dustin Smith
> Priority: Minor
> Labels: caching, sql, time
>
> If I call current_timestamp 3 times while caching the dataframe variable in
> order to freeze that dataframe's time, the 3rd dataframe time and beyond
> (4th, 5th, ...) will be frozen to the 2nd dataframe's time. The 1st dataframe
> and the 2nd will differ in time but will become static on the 3rd usage and
> beyond (when running on Zeppelin or Jupyter).
> Additionally, caching only caused 2 dataframes to cache skipping the 3rd.
> However,
> {code:java}
> val df = Seq(java.time.LocalDateTime.now.toString).toDF("datetime").cache
> df.count
> // this can be run 3 times no issue.
> // then later cast to TimestampType{code}
> doesn't have this problem and all 3 dataframes cache with correct times
> displaying.
> Running the code in shell and Jupyter or Zeppelin (ZP) also produces
> different results. In the shell, you only get 1 unique time no matter how
> many times you run it, current_timestamp. However, in ZP or Jupyter I have
> always received 2 unique times before it froze.
>
> {code:java}
> val df1 = spark.range(1).select(current_timestamp as "datetime").cache
> df1.count
> df1.show(false)
> Thread.sleep(9500)
> val df2 = spark.range(1).select(current_timestamp as "datetime").cache
> df2.count
> df2.show(false)
> Thread.sleep(9500)
> val df3 = spark.range(1).select(current_timestamp as "datetime").cache
> df3.count
> df3.show(false){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
