The problem with that approach is that you're not actually running
validations. It's fine if you want to do it that way in your environment,
this is why we make it easy to plug in your own `TableOperations`. But I
wouldn't recommend it or add that to the Iceberg library.
On Sat, Feb 19, 2022 at 4:
Hi everyone
The current spark2.4, spark3.0 have the following unaligned runtime
artifact names:
# Spark 2.4
iceberg-spark-runtime-0.13.1.jar
# Spark 3.0
iceberg-spark3-runtime-0.13.1.jar
# Spark 3.1
iceberg-spark-runtime-3.1_2.12-0.13.1.jar
# Spark 3.2
iceberg-spark-runtime-3.2_2.12-0.13.1.jar
>
I think option 2 is ideal, but I don't know if there is any hard
requirement from ASF/Maven Central side for us to keep backwards
compatibility of package names published in maven. If there is a
requirement then we cannot change it.
As a mitigation, I stated in https://iceberg.apache.org/multi-eng
I don't think it is best practice to just change the artifact name of
published jars. Unless we publish a new version with the new naming
convention.
On Mon, Feb 21, 2022 at 12:36 PM Jack Ye wrote:
> I think option 2 is ideal, but I don't know if there is any hard
> requirement from ASF/Maven Ce
Thanks for bringing this up Jeff!
Normally I agree, it’s not a good practice to change artifact name.
However, in this case, the artifact has changed already. The
“spark3-runtime” used to be for all versions of Spark 3 (at the time Spark
3.0 and 3.1). It no longer is, as it’s only tested / used wi
Agreed with Kyle. An artifact name of Spark3.0 like
iceberg-spark-runtime-3.0_2.12-0.13.1.jar is more accurate and consistent,
less confusing for users.
On Sun, Feb 20, 2022 at 10:47 PM Kyle Bendickson wrote:
> Thanks for bringing this up Jeff!
>
> Normally I agree, it’s not a good practice to