-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Enforce hive.translate-hive-views propertry #5636
Conversation
b290bb2
to
c151153
Compare
Should we throw exception here or just return Optional.empty() like before? I am doing following:
|
359532b
to
ed776a0
Compare
@laurachenyu your suggestion also looks good. One difference though is that previously the |
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 we should return Optional.empty()
when hive view is not supported. Otherwise it does make sense to have a method that returns Optional
when it fails in case it cannot return a value.
ConnectorMetadata metadata = transaction.getMetadata(); | ||
assertThatThrownBy(() -> metadata.getView(session, new SchemaTableName(database, tableName))) | ||
.isInstanceOf(HiveViewNotSupportedException.class) | ||
.hasMessageContaining("Hive views are not supported"); |
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 would be nice add a test where changing config property would actually return a view here.
We have product tests for that, so if adding a test here is problematic then maybe a comment would be enough.
ed776a0
to
3fc2b0e
Compare
Updated based on the suggestions, However, not sure if this is the best way to test. currently, it verifies the logic for In general, I feel that the testing related to view translation "integration" can be improved using one of the approaches below: approach-1: (similar to current updated PR)
approach-2:
approach-3:
I feel approach-2 and approach-3 might be easier, but approach-1 is more exhaustive. however, need to keep in mind that we don't overfit the code-implementation on the ease of testing :) |
@@ -314,7 +316,15 @@ else if (table.getTableType().equals(EXTERNAL_TABLE.name())) { | |||
@Override | |||
public synchronized Optional<Table> getTable(HiveIdentity identity, String databaseName, String tableName) | |||
{ | |||
return getTable(databaseName, tableName); | |||
Optional<Table> optionalTable = getTable(databaseName, tableName); |
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.
We shouldn't need any view specific logic in the metastore, as the metastore's job is to simply store/retrieve the table metadata. This specific check seems to be a sanity check that the file metastore doesn't contain a Hive view, but that should be impossible since the code is only used by Presto.
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.
got it, agreed. ThriftHiveMetastore::getAllViews
also involves usage of view specific config, may be we can move it out too in future.
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.
You're right, it's always had logic to do filtering based on presto_view
flag, but I forgot that it also has special logic based on whether or not we're translating Hive views. In that case, maybe it is required to add more logic to ThriftHiveMetastore
. Though FileHiveMetastore
doesn't have any today, so I'd need to be more convinced for that one.
@@ -343,6 +343,14 @@ public ThriftMetastoreStats getStats() | |||
.stopOnIllegalExceptions() | |||
.run("getTable", stats.getGetTable().wrap(() -> { | |||
Table table = getTableFromMetastore(identity, databaseName, tableName); | |||
|
|||
// Check if hive view is supported | |||
if (!translateHiveViews |
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.
Similar to the other comment, this check should be done in HiveMetadata
where the translation occurs.
{ | ||
String tableName = "test_hive_view"; | ||
ConnectorSession session = newSession(); | ||
Table table = Table.builder() |
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.
We shouldn't need to create a new Hive view here, as these tests already create presto_test_view
(referenced by the view
field in this class). It should be enough to call
metadata.getView(session, view);
The view translation logic should be independent of the metastore implementation (which is a "dumb" store in terms of view data) and thus so should the tests. The If it would make it easier, we could add a session property for this, then we could easily change it in the product test. |
3fc2b0e
to
7460b57
Compare
@electrum can you please take a look again? I've simplified the testing based on slack discussion, and just testing with Test failures were unrelated, retriggered to get a clean build. |
I agree, but note that product tests do not involve Glue today (#5426). I believe we do need both: product tests for "nice tests" and
@phd3 @electrum |
presto-hive-hadoop2/src/test/java/io/prestosql/plugin/hive/TestHive.java
Outdated
Show resolved
Hide resolved
7460b57
to
97c0a12
Compare
97c0a12
to
20961dc
Compare
Fixes #5623