tsungchih opened a new pull request, #7904:
URL: https://github.com/apache/gravitino/pull/7904
<!--
1. Title: [#<issue>] <type>(<scope>): <subject>
Examples:
- "[#123] feat(operator): support xxx"
- "[#233] fix: check null before access result in xxx"
- "[MINOR] refactor: fix typo in variable name"
- "[MINOR] docs: fix typo in README"
- "[#255] test: fix flaky test NameOfTheTest"
Reference: https://www.conventionalcommits.org/en/v1.0.0/
2. If the PR is unfinished, please mark this PR as draft.
-->
### What changes were proposed in this pull request?
This PR is aimed at introducing a `SerdesUtilsBase` class to accommodate
shared class variables so that they could be shared across all its sub-classes
like `SerdesUtils`. In doing so, we could
- achieve single source of truth against shared class variables,
- facilitate maintenance effort.
### Why are the changes needed?
The current implementation of `SerdesUtils` in client-python tries to split
`JsonUtils` in Java client into various classes listed as follows.
-
[gravitino.api.types.json_serdes._helper.serdes_utils.SerdesUtils](https://github.com/apache/gravitino/blob/main/clients/client-python/gravitino/api/types/json_serdes/_helper/serdes_utils.py)
-
[gravitino.dto.rel.expressions.json_serdes._helper.serdes_utils.SerdesUtils](https://github.com/apache/gravitino/blob/main/clients/client-python/gravitino/dto/rel/expressions/json_serdes/_helper/serdes_utils.py)
Many class variables (as serialized keys) are shared and therefore defined
more than once in the `SerdesUtils` class. In the end, we will define these
shared class variables in multiple `SerdesUtils`. This could introduce issues
of breaking single source of truth against these class variables (serialized
keys) and could be difficult to achieve consistency.
#5199
### Does this PR introduce _any_ user-facing change?
No
### How was this patch tested?
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]