Thank you for leading the discussion, Jungtaek.
+1 for voting because we couldn't build a unanimous consensus on this specific
topic.
Thanks,
Dongjoon.
On 2025/03/07 09:15:39 Jungtaek Lim wrote:
> I'll need to start VOTE to move this forward.
>
-1
SPARK-51029 (GitHub PR [1]) removes `hive-llap-common` from Spark binary
distribution, which technically
breaks the feature "Spark SQL supports integration of Hive UDFs, UDAFs and
UDTFs"[2], more precisely, it change
Hive UDF support from batteries included to not.
In details, when user runs
What is the problem with the existence of the migration logic? I understand
not keeping the misnamed config. But the migration logic does no harm other
than taking up a couple lines in the code, no?
Unless someone offers any reason this is an issue... what are we even
talking about.
Is the idea th
> Is the idea that the existence of the string 'databricks' in the code is
a problem? it is not.
This is the point where we have arguments. There is disagreement that this
is not just a string which I don't agree with, hence this discussion
thread. This is also why I want to see what is "evidence"
Sean, it's about how long we keep the vendor name in the codebase (since
the migration logic has the problematic config name as a string) for users.
We agreed in a previous discussion thread that "this is generally bad", so
we fixed the incorrect config name immediately in 3.5. Now it's just a
str
I don't understand the problem with keeping migration logic in for a long
time, just in case. Who cares, it's some bit of check buried somewhere in
the streaming code, much like deprecation warnings.
There is not somehow an ASF policy compelling the removal of such logic;
you are not _required_ to
