[Cherry-pick to branch-1.3] [#11844] feat(tag): Support tags for views and functions - #12714
Merged
jerryshao merged 7 commits intoAug 28, 2026
Merged
Conversation
…e#11897) ### What changes were proposed in this pull request? This PR adds tag support for VIEW and FUNCTION metadata objects. The changes include: - Allowing VIEW and FUNCTION in `TagManager` supported metadata object types. - Updating OpenAPI definitions for metadata object tag operations. - Cleaning up function tag relations when functions are dropped. - Cleaning up view/function tag relations during catalog and schema cascade deletion, including PostgreSQL-specific SQL providers. - Adding unit tests for tag association and cascade cleanup behavior. ### Why are the changes needed? Views and functions are first-class metadata objects in Gravitino, but they were excluded from tag association support. Users could not organize, classify, or discover views and functions through tags like other metadata objects. Fix: apache#11844 ### Does this PR introduce _any_ user-facing change? Yes. Users can now associate, list, get, and remove tags for VIEW and FUNCTION metadata objects through the existing metadata object tag REST APIs. ### How was this patch tested? Added unit tests covering: - TagManager support for VIEW and FUNCTION. - REST metadata object tag operations for VIEW and FUNCTION. - Tag relation cleanup when views/functions are dropped. - Catalog/schema cascade cleanup for view/function tag relations. - PostgreSQL tag relation cascade SQL provider coverage. Ran: ```bash ./gradlew :core:test --tests org.apache.gravitino.storage.relational.mapper.provider.postgresql.TestTagMetadataObjectRelPostgreSQLProvider --tests org.apache.gravitino.storage.relational.service.TestSchemaMetaService --tests org.apache.gravitino.storage.relational.service.TestCatalogMetaService ``` (cherry picked from commit b464820)
apache#11903) This PR adds Java client support for tag operations on views and functions. Changes include: - Add default `supportsTags()` methods to the `View` and `Function` API interfaces. - Add `GenericView` and `GenericFunction` client wrappers backed by `MetadataObjectTagOperations`. - Return tag-capable wrappers from Java client view and function operations. - Add Java client tests for view/function tag support. metadata objects. The Java client should expose the same capability so users can manage tags for views and functions through the typed client API, consistent with other tag-capable metadata objects. Fix: apache#11902 Related: apache#11844 Yes. Java client users can now call `supportsTags()` on `View` and `Function` objects returned by the client, for example: ```java view.supportsTags().associateTags(...); function.supportsTags().listTags(); ``` - `./gradlew :clients:client-java:test -PskipITs` --------- Co-authored-by: Jerry Shao <jerryshao@datastrato.com> (cherry picked from commit e71af9c)
…12040) ### What changes were proposed in this pull request? This PR adds the public Python API definitions required for view support. The changes include: - Add `View`, `ViewCatalog`, and `ViewChange`. - Add `Representation`, `SQLRepresentation`, and predefined SQL dialects. - Add `Catalog.as_view_catalog()`. - Add view-specific exception types. - Add unit tests for view representations and changes. ### Why are the changes needed? The Python client currently lacks the public API contracts required to represent and manage views. Fix: apache#12039 ### Does this PR introduce _any_ user-facing change? Yes. It adds public Python API definitions for views. ### How was this patch tested? Added unit tests for `View`, `ViewChange`, and `SQLRepresentation`. The formatting, lint, and unit test checks passed. (cherry picked from commit c10925a)
… models (apache#12090) ### What changes were proposed in this pull request? - Add `GenericView` as the client-side implementation of `View`. - Add DTOs for views and SQL representations. - Add polymorphic JSON serialization for view representations. - Extend `DTOConverters` with representation conversions. - Add unit tests for the new models, serialization, and conversions. ### Why are the changes needed? The Python client needs concrete view models and serialization support before view catalog operations can consume and return view metadata. Fix: apache#12089 ### Does this PR introduce _any_ user-facing change? No. This PR adds the supporting client-side models. View catalog operations will be added separately. ### How was this patch tested? Added unit tests covering `GenericView`, view and representation DTOs, representation serialization, and DTO conversions. Python client formatting, lint, and unit tests pass. (cherry picked from commit 648fdd7)
…tions (apache#12117) ### What changes were proposed in this pull request? - Extend `RelationalCatalog` with `ViewCatalog`. - Add `as_view_catalog`, `create_view`, and `drop_view`. - Add request and response DTOs for view creation. - Add view-specific REST error handling. - Generalize the entity namespace helper for table and view operations. - Add corresponding unit and integration tests. ### Why are the changes needed? The Python client currently lacks support for view create/drop operations. These changes allow users to create and drop views through the Python client. Fix: apache#12116 ### Does this PR introduce _any_ user-facing change? Yes. Python client users can now create and drop views through `RelationalCatalog.as_view_catalog()`. ### How was this patch tested? Added unit tests for request and response validation, REST error handling, and view create/drop operations. Added integration tests covering view creation, duplicate creation, view deletion, and deletion of nonexistent views. (cherry picked from commit 941f030)
…tions (apache#12159) ### What changes were proposed in this pull request? - Add view list, load, existence check, and alter operations to `RelationalCatalog`. - Add request DTOs for view updates. - Support rename, set/remove property, and replace view changes. - Add corresponding unit and integration tests. ### Why are the changes needed? The Python client currently supports view create/drop operations but lacks view query/alter operations. These changes complete the basic view management workflow through the Python client. Fix: apache#12158 ### Does this PR introduce _any_ user-facing change? Yes. Python client users can now list, load, check, and alter views through `RelationalCatalog.as_view_catalog()`. ### How was this patch tested? Added unit tests for view query operations, update request conversion, serialization, validation, and error handling. Added integration tests covering view listing, loading, existence checks, property updates, and related error cases. (cherry picked from commit 2214a29)
…ons (apache#12182) ### What changes were proposed in this pull request? This PR adds Python client support for tag operations on views and functions. Changes include: - Add default `supports_tags()` methods to the `View` and `Function` API classes. - Extend `GenericView` and `GenericFunction` with tag operations backed by `MetadataObjectTagOperations`. - Return tag-capable wrappers from Python client view and function operations. - Add Python client unit and integration tests for view/function tag support. ### Why are the changes needed? apache#11844 enables server-side tag association for `VIEW` and `FUNCTION` metadata objects. The Python client should expose the same capability so users can manage tags for views and functions through the typed client API, consistent with other tag-capable metadata objects. Fix: apache#12181 Related: apache#11844 ### Does this PR introduce _any_ user-facing change? Yes. Python client users can now call `supports_tags()` on `View` and `Function` objects returned by the client, for example: ```python view.supports_tags().associate_tags(...) function.supports_tags().list_tags() ``` ### How was this patch tested? - `./gradlew :clients:client-python:black :clients:client-python:pylint :clients:client-python:unitTests` - `./gradlew :clients:client-python:integrationTest` (cherry picked from commit a7d221c)
Contributor
Author
|
NOTE. I will use rebase and merge. |
Code Coverage Report
Files
|
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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?
This PR backports view/function tag support from
maintobranch-1.3:and FUNCTION as taggable metadata object types, OpenAPI updates, cascade cleanup on drop.
supportsTags()toView/Function,GenericView/GenericFunctionclient wrappers.supports_tags()to the Python client'sView/Function.The Python client had no View API at all on
branch-1.3(it was added onmainafter thebranch was cut), so 4 prerequisite commits are included to bring it to parity before applying
the tag-support patch:
One trivial doc conflict in
docs/manage-tags-in-gravitino.mdwas resolved manually: the introtext that #11903 added (listing taggable object types) is redundant with
branch-1.3's existing,already-restructured
docs/tags.md, which already listsVIEW/FUNCTIONas taggable.Why are the changes needed?
Feature parity:
branch-1.3should support tagging views and functions consistently acrossserver, Java client, and Python client, matching
main.Fix: #11844
Related: #11902, #12181
Does this PR introduce any user-facing change?
Yes, same as the source PRs:
VIEWandFUNCTIONare now valid metadata object types for tag association.view.supportsTags()/function.supportsTags()are available.view.supports_tags()/function.supports_tags(); the Python client alsogains full View CRUD (list/load/create/alter/drop) it previously lacked on
branch-1.3.How was this patch tested?
./gradlew :api:compileJava :core:compileJava :clients:client-java:compileJava :clients:client-java:compileTestJava -q— passed../gradlew :clients:client-java:test --tests "*TestSupportTags*" --tests "*TestFunctionCatalog*" --tests "*TagIT*" -PskipITs -q— passed../gradlew :core:test --tests "org.apache.gravitino.tag.TestTagManager" -PskipITs -q— passed in isolation.python -m pytest tests/unittests -k "view or function or tag" -q— 190 passed.