-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Core: rename WRITE_NEW_DATA_LOCATION to WRITE_FOLDER_STORAGE_LOCATION #2965
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -114,7 +114,7 @@ public void testDefaultLocationProvider() { | |
| @Test | ||
| public void testDefaultLocationProviderWithCustomDataLocation() { | ||
| this.table.updateProperties() | ||
| .set(TableProperties.WRITE_NEW_DATA_LOCATION, "new_location") | ||
| .set(TableProperties.WRITE_FOLDER_STORAGE_LOCATION, "new_location") | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it make sense to leave a test for the deprecated config value? I’d love to even log something if a user sets it, but that can be considered later (if at all).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is the same value, just using a different name to avoid confusion.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I see now. This won't affect any external folks unless they have some custom stuff that touches this config. |
||
| .commit(); | ||
|
|
||
| this.table.locationProvider().newDataLocation("my_file"); | ||
|
|
@@ -224,7 +224,7 @@ public void testObjectStorageLocationProviderPathResolution() { | |
|
|
||
| String folderPath = "s3://random/folder/location"; | ||
| table.updateProperties() | ||
| .set(TableProperties.WRITE_NEW_DATA_LOCATION, folderPath) | ||
| .set(TableProperties.WRITE_FOLDER_STORAGE_LOCATION, folderPath) | ||
| .commit(); | ||
|
|
||
| Assert.assertTrue("folder storage path should be used when set", | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to the deprecation.
When the deprecation comes around, we should consider providing an action to migrate tables off of deprecated properties. In general, I think that would allow us to make smarter decisions about table property names as new needs surface. Something similar to the v2 table migration action. But that’s a long ways off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think migration is unnecessary. The actual value stored is always
write.folder-storage.path, we are just changing the Java variable name. And as I noted, we will deprecate after 2 releases, so that people can have time to change their variable name.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why will be removed in
0.14.0? Is there a convention to follow?