BTW, I forgot to add my opinion explicitly in this thread because I was on
the PR before this thread.
1. The `FunctionCatalog API` PR was made on May 9, 2019 and has been there
for almost two years.
2. I already gave my +1 on that PR last Saturday because I agreed with the
latest updated design
+1
I looked around the jira tickets and I think there is no explicit blocker
issue on the Spark SQL component.
Also, I ran the tests on AWS envs and I couldn't find any issue there, too.
Bests,
Takeshi
On Thu, Feb 11, 2021 at 7:37 AM Mridul Muralidharan
wrote:
>
> Signatures, digests, etc
Signatures, digests, etc check out fine.
Checked out tag and build/tested with -Pyarn -Phadoop-2.7 -Phive
-Phive-thriftserver -Pmesos -Pkubernetes
I keep getting test failures
with org.apache.spark.sql.kafka010.KafkaDelegationTokenSuite: removing this
suite gets the build through though - does
Hi,
This is just an extra unnecessary usage of the /sparkConf/ member val
directly (those two lines are added by two different PRs).
Actually both uses the same /sparkConf/ to give back the config value, as
/KubernetesExecutorConf/ extends the /KubernetesConf/ [1] which uses the
passed
Hi, Ryan.
We didn't move past anything (both yours and Wenchen's). What Wenchen
suggested is double-checking the alternatives with the implementation to
give more momentum to our discussion.
Your new suggestion about optional extention also sounds like a new
reasonable alternative to me.
We are
I don’t think we should so quickly move past the drawbacks of this
approach. The problems are significant enough that using invoke is not
sufficient on its own. But, I think we can add it as an optional extension
to shore up the weaknesses.
Here’s a summary of the drawbacks:
- Magic function
Thank you all for making a giant move forward for Apache Spark 3.2.0.
I'm really looking forward to seeing Wenchen's implementation.
That would be greatly helpful to make a decision!
> I'll implement my idea after the holiday and then we can have
more effective discussions. We can also do
