I have some concerns on the issue of silent behavior change that Steve
Zhang raised in the PR comment.  E.g., users may set the location based on
the deprecated table property, With this change, it would silently switch
to a new location. This can potentially mess up orphan file cleanup etc.

Maybe we should consider the more conservative two-step approach that Steve
mentioned (1) in the next release of 1.9, fail when those properties were
defined in the table (2) remove those properties' references maybe in 2.0.

On Mon, Feb 17, 2025 at 2:17 PM Kevin Liu <kevinjq...@apache.org> wrote:

> +1 for removing. Thanks for taking up the cleanup duty!
>
> I looked up the usage for the property and its string value with github
> search, and confirmed that they are not used.
>
> Also, for reference, here are the previous related PRs:
> https://github.com/apache/iceberg/pull/3094
> https://github.com/apache/iceberg/pull/2965
>
> Best,
> Kevin Liu
>
> On Mon, Feb 17, 2025 at 2:06 PM Yufei Gu <flyrain...@gmail.com> wrote:
>
>> +1 to remove them.
>> Yufei
>>
>>
>> On Mon, Feb 17, 2025 at 1:26 PM Steve Zhang
>> <hongyue_zh...@apple.com.invalid> wrote:
>>
>>> Thanks Fokko for removing deprecated properties!
>>>
>>> Just want to highlight the worst case for tables with old configuration
>>> and not aware of this deprecation might experience silent behavior change.
>>> But considering this has been deprecated for past 3 years, here’s my +1.
>>>
>>> Thanks,
>>> Steve Zhang
>>>
>>>
>>>
>>> On Feb 17, 2025, at 2:18 AM, Fokko Driesprong <fo...@apache.org> wrote:
>>>
>>> Hi everyone,
>>>
>>> While reviewing the LocationProvider equivalent of PyIceberg, I noticed
>>> some old code in the Java codebase that I felt could be cleaned up. You
>>> can find the PR over here <https://github.com/apache/iceberg/pull/12174>.
>>> This one removes the deprecated properties:
>>>
>>> OBJECT_STORE_PATH = "write.object-storage.path";
>>> WRITE_FOLDER_STORAGE_LOCATION = "write.folder-storage.path";
>>>
>>> These have been deprecated since Iceberg 0.12, and would like to know if
>>> anyone has any concerns about removing these.
>>>
>>> Kind regards,
>>> Fokko
>>>
>>>
>>>

Reply via email to