dramaticlly commented on code in PR #8194:
URL: https://github.com/apache/iceberg/pull/8194#discussion_r1284740218
##########
core/src/main/java/org/apache/iceberg/TableProperties.java:
##########
@@ -365,4 +365,7 @@ private TableProperties() {}
public static final String UPSERT_ENABLED = "write.upsert.enabled";
public static final boolean UPSERT_ENABLED_DEFAULT = false;
+
+ public static final String UNIQUE_LOCATION = "location.unique";
Review Comment:
hey @anigos thank you explaining your thoughts. I want to share some of mine
below
> Once a table got created in past that defintely has a valid path do we
really needs to check fileIO or a simple string comparison/regex match is
enough?
As issue #7238 mentioned, there's a lot of suggestions to avoid conflict but
not all are equally practical to handle real world complexity
- existing table whose location does not follow
`<bucket_uri>/<database_hash>/<database_name>/<table_name>` pattern, the
directory based location is a convention for hive tables but not for iceberg.
- FileIO runtime resolve provides us the ability to check if the given path
is already in use/non-empty at runtime where table location based
comparison/regex match rely on good intention of data owner who followed
convention. So if io is available at the time of table creation, I think we can
take that to our advantage.
- table rename with old location is the fine as I also include some of them
in unit tests
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
