Github user kunalkhamar commented on a diff in the pull request:
https://github.com/apache/spark/pull/17379#discussion_r107821546
--- Diff:
sql/core/src/main/scala/org/apache/spark/sql/internal/SessionState.scala ---
@@ -134,17 +131,20 @@ private[sql] class SessionState(
SessionState.mergeSparkConf(confCopy, sparkContext.getConf)
- new SessionState(
- sparkContext,
- newSparkSession.sharedState,
- confCopy,
- experimentalMethods.clone(),
- functionRegistryCopy,
- catalogCopy,
- sqlParser,
- SessionState.createAnalyzer(newSparkSession, catalogCopy, confCopy),
- new StreamingQueryManager(newSparkSession),
- queryExecutionCreator)
+ val newSessionState = new SessionState(
+ sparkContext,
+ newSparkSession.sharedState,
+ confCopy,
+ experimentalMethods.clone(),
+ functionRegistryCopy,
+ catalogCopy,
+ sqlParser,
+ SessionState.createAnalyzer(newSparkSession, catalogCopy,
confCopy),
+ new StreamingQueryManager(newSparkSession),
+ queryExecutionCreator) {
+ override val listenerManager: ExecutionListenerManager =
self.listenerManager.clone()
--- End diff --
I think the general rule we followed in the cloneSession PR is that `val`s
that directly depend on `SparkSession` to be initialized, are to be constructor
params. We leave the other `val`s in the body of class.
The advantage here is less duplicated code between `SessionState`,
`HiveSessionState` and `TestHiveSparkSession`.
This is consistent with that, what would be the advantage of changing it to
be a param?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
