[FEATURE] asynchronous operations of Gravitino
- Dominant language
- Java
- Stars
- 3.2k
- Forks
- 935
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 315
Description
### Describe the feature
Currently, all operations in Gravitino are synchronized.
asynchronous operations in some situation is necessary, for example, when user drop table with too many partitions by hmsClient.dropTable, it may cost too much time so that the interface will be timeout.
### Motivation
_No response_
### Describe the solution
_No response_
### Additional context
_No response_
Contributor guide
Research direction
The issue names hmsClient.dropTable as the slow operation; start there and trace how dropping tables with many partitions currently executes. No files or tests are identified, so clarify which operations should be asynchronous, their completion behavior, and what prevents interface timeouts before defining tests and a done condition.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend-api-design, databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100