Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
DeltaCatalog.createTable should respect PROP_IS_MANAGED_LOCATION #3654
DeltaCatalog.createTable should respect PROP_IS_MANAGED_LOCATION #3654
Changes from 1 commit
89c5783
835b618
0c0855c
2b41714
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
TableCatalog also seems to have
PROP_EXTERNAL
? Is this also serving the same purpose? What happens when bothPROP_EXTERNAL
andPROP_IS_MANAGED_LOCATION
are set to true?Since we are making DeltaCatalog aware of the
TableCatalog.PROP_IS_MANAGED_LOCATION
, should we also make it aware ofPROP_EXTERNAL
for the sake of completeness in this PR itself?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
I also think we should add asserts and checks here so that UC-Spark catalog never sets these mutually exclusive properly inconsistently.
same comments i made in the linked PR - https://github.com/unitycatalog/unitycatalog/pull/449/files#r1750747701
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.
The
PROP_EXTERNAL
should only be true if the CREATE TABLE command has the keywordEXTERNAL
specified. For example,CREATE EXTERNAL TABLE t ...
. It should not be true even if the keywordLOCATION
is specified likeCREATE TABLE t ... LOCATION ...
, although most catalogs will create this table as external table since it has a user-specified location.On the other hand,
PROP_IS_MANAGED_LOCATION
is used to indicate that the location is not user-specified by managed by the system.That said, these two properties are not mutually exclusive. In fact,
DeltaCatalog
does not look at thePROP_EXTERNAL
property at all.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.
Also see unitycatalog/unitycatalog#449 (comment)
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.
so its possible that
CREATE EXTERNAL TABLE ... <no location specified>
command can producePROP_EXTERNAL = true
andPROP_IS_MANAGED_LOCATION=true
if the Spark custom catalog calling into DeltaCatalog decides to generate a location even for an external table... right?And in that case, this code will produce a managed table, even though the SQL command explicitly asked for
create external table
... right?That's what I dont like about this overall setup. Yes, you are right they are not mutually exclusive, but setting both of them to true, while possible, is very very ambiguous.
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.
It is upto the catalog impl to decide how they want to proceed in such scenario? Can we add an assertion in Delta to fail in such a scenario?
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.
Delta is more like a proxy and it will eventually forward the request to HMS/UC or whatever custom catalog. I think it's better to leave it to the underlying catalog to enforce it.
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.
Anyway, this is not an issue for now as neither HMS nor UC generate location for external tables.
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.
It is fine for now. Thats why i merged the PR. But it always good to think of future proofing things so that there are no surprises in the future when somebody also loads DeltaCatalog with other catalogs.
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.
What will be the impact of this PR with non-UC catalogs like HMS if we backport this to branch 3.2?
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.
or should we make it safer to backport by using the isUnityCatalog flag here as well?
I think its better we use the flag.