[#3483] refactor(API): separate API for client using: SupportsSchemas #3419
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shaofengshi
changed the title
|
@shaofengshi can you use a separate issue to track this work? |
jerryshao
reviewed
May 21, 2024
jerryshao
reviewed
May 21, 2024
jerryshao
reviewed
May 21, 2024
jerryshao
reviewed
May 21, 2024
core/src/test/java/com/datastrato/gravitino/TestCatalogOperations.java
Outdated
Show resolved
Hide resolved
jerryshao
reviewed
May 21, 2024
core/src/main/java/com/datastrato/gravitino/catalog/Catalog.java
Outdated
Show resolved
Hide resolved
yuqi1129
reviewed
May 21, 2024
api/src/main/java/com/datastrato/gravitino/CatalogBasicInfo.java
Outdated
Show resolved
Hide resolved
I see; the issue has been closed with the previous PR. OK let me create another. |
shaofengshi
changed the title
shaofengshi
changed the title
jerryshao
changed the title
jerryshao
reviewed
May 22, 2024
core/src/main/java/com/datastrato/gravitino/schema/SupportsSchemas.java
Outdated
Show resolved
Hide resolved
jerryshao
approved these changes
May 22, 2024
diqiu50
pushed a commit
to diqiu50/gravitino
that referenced
this pull request
Jun 13, 2024
…chemas (apache#3419) ### What changes were proposed in this pull request? Today Gravitino java client and server sides share the same interfaces, like SupportsMetalakes, SupportsCatalogs, SupportsSchemas, etc. These interfaces are good for server side, but not good for client side. After some discussion with Jerry and others, if we want to make it easier to use, and still keep server side code stable, the only way is to separate the APIs: create individual APIs for the java client. This PR will introduce the simplified API for client: SupportsSchemas. The interface for serverside has been moved into core module with package name "com.datastrato.gravitino.schema"; The current one in api module with package name "com.datastrato.gravitino.rel" is for client side, whose method signatures have been changed, so the client code will be clear. Besides, the "Catalog.asSchema()", "Catalog.asTableCatalog()" should only be implemented on the client side, not server side (as server side we can use the subclasses of "CatalogOperations"). I updated the occurrances of such usages, mainly in some integration tests. The integration tests which uses Java client to manipulate metadata also be updated. ### Why are the changes needed? To make the client API simple and easy to use. Fix: apache#3483 ### Does this PR introduce _any_ user-facing change? Will change the Java client API, mainly on the method signatures; for example, "listSchemas()" won't need an input parameter, "schemaExists()" will use a String value as the input parameter instead of a NameIdentifier object, etc. ### How was this patch tested? All existing integration tests will cover the API change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What changes were proposed in this pull request?
Today Gravitino java client and server sides share the same interfaces, like SupportsMetalakes, SupportsCatalogs, SupportsSchemas, etc. These interfaces are good for server side, but not good for client side. After some discussion with Jerry and others, if we want to make it easier to use, and still keep server side code stable, the only way is to separate the APIs: create individual APIs for the java client.
This PR will introduce the simplified API for client: SupportsSchemas. The interface for serverside has been moved into core module with package name "com.datastrato.gravitino.schema"; The current one in api module with package name "com.datastrato.gravitino.rel" is for client side, whose method signatures have been changed, so the client code will be clear.
Besides, the "Catalog.asSchema()", "Catalog.asTableCatalog()" should only be implemented on the client side, not server side (as server side we can use the subclasses of "CatalogOperations"). I updated the occurrances of such usages, mainly in some integration tests.
The integration tests which uses Java client to manipulate metadata also be updated.
Why are the changes needed?
To make the client API simple and easy to use.
Fix: #3483
Does this PR introduce any user-facing change?
Will change the Java client API, mainly on the method signatures; for example, "listSchemas()" won't need an input parameter, "schemaExists()" will use a String value as the input parameter instead of a NameIdentifier object, etc.
How was this patch tested?
All existing integration tests will cover the API change.