You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@amoro.apache.org by "zhangwl9 (via GitHub)" <gi...@apache.org> on 2026/05/29 04:58:42 UTC
[PR] [AMORO-4236] Add Maintenance tab for table process management [amoro]
zhangwl9 opened a new pull request, #4238:
URL: https://github.com/apache/amoro/pull/4238
<!--
Thanks for sending a pull request!
Here are some tips for you:
1. If this is your first time, please read our contributor guidelines: https://amoro.apache.org/how-to-contribute/
2. If the PR is related to an issue in https://github.com/apache/amoro/issues, add '[AMORO-XXXX]' in your PR title, e.g., '[AMORO-XXXX] Your PR title ...'.
3. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP][AMORO-XXXX] Your PR title ...'.
-->
## Why are the changes needed?
<!--
Please clarify why the changes are needed. For instance,
1. If you add a feature, you can talk about its use case.
2. If you fix a bug, you can clarify why it is a bug.
3. Use Fix/Resolve/Close #{ISSUE_NUMBER} to link this PR to its related issue
-->
Close #4236.
## Brief change log
<!--
Clearly describe the changes made in modules, classes, methods, etc.
-->
This PR introduces a dedicated Maintenance tab in the table details page to separate maintenance processes (cleanup operations) from optimizing processes, improving user experience and operational clarity.
Key changes:
- Backend: Add `processCategory` parameter to `getOptimizingProcessesInfo` API to filter by OPTIMIZING or MAINTENANCE category
- Backend: Add new REST endpoint `/maintenance-types` to fetch maintenance-specific process types
- Backend: Update `MixedAndIcebergTableDescriptor` to support category-based filtering with proper type separation
- Frontend: Create reusable `Maintenance.vue` component that wraps `Optimizing.vue` with maintenance-specific configuration
- Frontend: Add `processCategory` and `cancelModalTitleKey` props to `Optimizing.vue` for flexible reuse
- Frontend: Register Maintenance tab in table details page alongside Optimizing tab
## How was this patch tested?
- [ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible
- [x] Add screenshots for manual tests if appropriate
<img width="1953" height="952" alt="iShot_2026-05-29_12 47 22" src="https://github.com/user-attachments/assets/1cd3d570-005d-4fe7-8a6c-358cba0d590a" />
- [x] Run test locally before making a pull request
## Documentation
- Does this pull request introduce a new feature? (yes / no)
- If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
--
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: commits-unsubscribe@amoro.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [AMORO-4236] Add Maintenance tab for table process management [amoro]
Posted by "zhoujinsong (via GitHub)" <gi...@apache.org>.
zhoujinsong commented on PR #4238:
URL: https://github.com/apache/amoro/pull/4238#issuecomment-4608833115
**Overall: Good design direction, but suggest refining the category taxonomy before merging.**
The idea of separating table processes into different tabs is great. However, I think `MAINTENANCE` is too broad a category and we should consider a more precise taxonomy that better aligns with the nature of these operations.
### Suggested Classification
Instead of a binary `OPTIMIZING` / `MAINTENANCE` split, I'd suggest a three-way classification:
| Category | Purpose | Current Operations | Future Extensions |
|----------|---------|-------------------|-------------------|
| **OPTIMIZING** | Performance optimization (data reorganization) | Minor / Major / Full Compaction | Clustering, Sort Rewrite |
| **CLEANUP** | Space reclamation & lifecycle management | Expire Snapshots, Expire Data, Clean Orphan Files, Clean Dangling Delete Files | VACUUM, Remove Old Metadata |
| **PROFILING** | Information enrichment & metadata augmentation | Auto Create Tags | Collect Statistics, Build Index |
Additionally, `Sync Hive Tables` is more of an internal implementation detail and probably should **not** be exposed to users in any tab.
### Rationale
- "Maintenance" is too vague — compaction could also be considered "maintenance" in a broad sense.
- The operations currently under `MAINTENANCE` actually serve two distinct purposes: space reclamation (Expire/Clean) vs. metadata enrichment (Auto Create Tags). As we add more operations (e.g., statistics collection), this distinction will become more important.
- This three-way split aligns with industry conventions: Delta Lake has `OPTIMIZE` / `VACUUM`, Iceberg docs separate "rewrite" from "expire/remove".
### Suggested Approach
For the **backend API**, I'd recommend defining three `processCategory` values upfront: `OPTIMIZING`, `CLEANUP`, `PROFILING`. This makes the API future-proof.
For the **frontend**, there are two pragmatic options:
1. **Three tabs** (`Optimizing` / `Cleanup` / `Profiling`) — cleanest separation
2. **Two tabs for now** (`Optimizing` / `Cleanup`) — merge Profiling into Cleanup since there's currently only one profiling operation (Auto Create Tags), and split it out later when more profiling operations are added
Either way, the endpoint could be generalized from `/maintenance-types` to something like `/process-types?category=CLEANUP` for better extensibility.
What do you think?
--
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: commits-unsubscribe@amoro.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [AMORO-4236] Splitting the “Optimizing” tab into the “Optimizing” tab,“Cleanup” tab and “Profiling” tab [amoro]
Posted by "zhangwl9 (via GitHub)" <gi...@apache.org>.
zhangwl9 commented on PR #4238:
URL: https://github.com/apache/amoro/pull/4238#issuecomment-4647234992
> The current design introduces two static methods (`resolveCategoryTypes` and `matchProcessCategory`) in `FormatTableDescriptor`, where each descriptor implementation maintains its own type lists and passes them as arguments. This is a bit awkward — the routing logic is split between the caller and the interface.
>
> A cleaner approach would be to add an instance method to the interface:
>
> ```java
> /**
> * Returns the list of process type names belonging to the given category.
> * Used internally to filter processes by category.
> */
> default List<String> getProcessTypesByCategory(String processCategory) {
> return Collections.emptyList();
> }
> ```
>
> Each descriptor overrides this to return its own category-to-types mapping:
>
> ```java
> // MixedAndIcebergTableDescriptor
> @Override
> public List<String> getProcessTypesByCategory(String processCategory) {
> return FormatTableDescriptor.resolveCategoryTypes(
> processCategory, OPTIMIZING_TYPE_LIST, CLEANUP_TYPE_LIST, PROFILING_TYPE_LIST);
> }
>
> // HudiTableDescriptor / PaimonTableDescriptor
> @Override
> public List<String> getProcessTypesByCategory(String processCategory) {
> if (ProcessCategory.OPTIMIZING.getName().equalsIgnoreCase(processCategory)) {
> return OPTIMIZING_TYPES;
> }
> return Collections.emptyList();
> }
> ```
>
> Then `getOptimizingProcessesInfo` just calls `descriptor.getProcessTypesByCategory(processCategory)` without needing to know about the three separate lists. The two static helpers can be removed or made private.
>
> This keeps the "what types belong to my category" knowledge encapsulated in each descriptor, and makes the interface easier to extend when new categories are added.
Thank you very much. The new commit has been fixed it.
--
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: commits-unsubscribe@amoro.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [AMORO-4236] Splitting the “Optimizing” tab into the “Optimizing” tab,“Cleanup” tab and “Profiling” tab [amoro]
Posted by "zhoujinsong (via GitHub)" <gi...@apache.org>.
zhoujinsong merged PR #4238:
URL: https://github.com/apache/amoro/pull/4238
--
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: commits-unsubscribe@amoro.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [AMORO-4236] Add Maintenance tab for table process management [amoro]
Posted by "zhangwl9 (via GitHub)" <gi...@apache.org>.
zhangwl9 commented on PR #4238:
URL: https://github.com/apache/amoro/pull/4238#issuecomment-4627673199
> **Overall: Good design direction, but suggest refining the category taxonomy before merging.**
>
> The idea of separating table processes into different tabs is great. However, I think `MAINTENANCE` is too broad a category and we should consider a more precise taxonomy that better aligns with the nature of these operations.
>
> ### Suggested Classification
> Instead of a binary `OPTIMIZING` / `MAINTENANCE` split, I'd suggest a three-way classification:
>
> Category Purpose Current Operations Future Extensions
> **OPTIMIZING** Performance optimization (data reorganization) Minor / Major / Full Compaction Clustering, Sort Rewrite
> **CLEANUP** Space reclamation & lifecycle management Expire Snapshots, Expire Data, Clean Orphan Files, Clean Dangling Delete Files VACUUM, Remove Old Metadata
> **PROFILING** Information enrichment & metadata augmentation Auto Create Tags Collect Statistics, Build Index
> Additionally, `Sync Hive Tables` is more of an internal implementation detail and probably should **not** be exposed to users in any tab.
>
> ### Rationale
> * "Maintenance" is too vague — compaction could also be considered "maintenance" in a broad sense.
> * The operations currently under `MAINTENANCE` actually serve two distinct purposes: space reclamation (Expire/Clean) vs. metadata enrichment (Auto Create Tags). As we add more operations (e.g., statistics collection), this distinction will become more important.
> * This three-way split aligns with industry conventions: Delta Lake has `OPTIMIZE` / `VACUUM`, Iceberg docs separate "rewrite" from "expire/remove".
>
> ### Suggested Approach
> For the **backend API**, I'd recommend defining three `processCategory` values upfront: `OPTIMIZING`, `CLEANUP`, `PROFILING`. This makes the API future-proof.
>
> For the **frontend**, there are two pragmatic options:
>
> 1. **Three tabs** (`Optimizing` / `Cleanup` / `Profiling`) — cleanest separation
> 2. **Two tabs for now** (`Optimizing` / `Cleanup`) — merge Profiling into Cleanup since there's currently only one profiling operation (Auto Create Tags), and split it out later when more profiling operations are added
>
> Either way, the endpoint could be generalized from `/maintenance-types` to something like `/process-types?category=CLEANUP` for better extensibility.
>
> What do you think?
the new pr fix it.
Changes:
- Add ProcessCategory enum with OPTIMIZING, CLEANUP, PROFILING
- Replace getTableMaintenanceTypes() with getTableProcessTypes(category)
- Remove excludeTypes parameter from TableProcessMapper.listProcessMeta()
- Merge /optimizing-types and /maintenance-types into /process-types endpoint
- Split Maintenance.vue into Cleanup.vue and Profiling.vue
- Update HudiTableDescriptor and PaimonTableDescriptor
- Fix TestIcebergServerTableDescriptor to pass processCategory parameter
BREAKING CHANGE: Removed /optimizing-types and /maintenance-types REST
endpoints. Use /process-types?processCategory=OPTIMIZING|CLEANUP|PROFILING.
SPI method getTableMaintenanceTypes() replaced by getTableProcessTypes().
--
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: commits-unsubscribe@amoro.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] [AMORO-4236] Splitting the “Optimizing” tab into the “Optimizing” tab,“Cleanup” tab and “Profiling” tab [amoro]
Posted by "zhoujinsong (via GitHub)" <gi...@apache.org>.
zhoujinsong commented on PR #4238:
URL: https://github.com/apache/amoro/pull/4238#issuecomment-4646772827
The current design introduces two static methods (`resolveCategoryTypes` and `matchProcessCategory`) in `FormatTableDescriptor`, where each descriptor implementation maintains its own type lists and passes them as arguments. This is a bit awkward — the routing logic is split between the caller and the interface.
A cleaner approach would be to add an instance method to the interface:
```java
/**
* Returns the list of process type names belonging to the given category.
* Used internally to filter processes by category.
*/
default List<String> getProcessTypesByCategory(String processCategory) {
return Collections.emptyList();
}
```
Each descriptor overrides this to return its own category-to-types mapping:
```java
// MixedAndIcebergTableDescriptor
@Override
public List<String> getProcessTypesByCategory(String processCategory) {
return FormatTableDescriptor.resolveCategoryTypes(
processCategory, OPTIMIZING_TYPE_LIST, CLEANUP_TYPE_LIST, PROFILING_TYPE_LIST);
}
// HudiTableDescriptor / PaimonTableDescriptor
@Override
public List<String> getProcessTypesByCategory(String processCategory) {
if (ProcessCategory.OPTIMIZING.getName().equalsIgnoreCase(processCategory)) {
return OPTIMIZING_TYPES;
}
return Collections.emptyList();
}
```
Then `getOptimizingProcessesInfo` just calls `descriptor.getProcessTypesByCategory(processCategory)` without needing to know about the three separate lists. The two static helpers can be removed or made private.
This keeps the "what types belong to my category" knowledge encapsulated in each descriptor, and makes the interface easier to extend when new categories are added.
--
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: commits-unsubscribe@amoro.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org