[
https://issues.apache.org/jira/browse/HDDS-13362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-13362:
-------------------------------
Description:
We need to ensure that abstract OM response class should NOT have
CleanupTableInfo annotation since the OM response subclass CleanupTableInfo
annotation values will override the parent CleanupTableInfo. The abstract class
@CleanupTableInfo will tempt contributors to exclude it in the CleanupTableInfo
of the subclasses. It is also difficult to keep track the inheritance if we
have more than one level of subclasses (e.g. OMKeyCreateResponseWithFSO extends
OMFileCreateResponseWithFSO extends OMFileCreateResponse)
Currently we have these abstract classes:
* AbstractS3MultipartAbortResponse
* AbstractOMKeyDeleteResponse
We can push the CleanupTableInfo of these abstract classes to the all the sub
concrete classes. After that we need to write a test to ensure that all the
concrete classes contain CleanupTableInfo and it contains all the
CleanupTableInfo of all the parent abstract classes.
Ideally, CleanupTableInfo should be built by checking the
OMClientRequest#validateAndUpdateCache implementation for any cache update,
instead of hardcoding CleanupTableInfo in the OM response, which is very prone
to human error. However, this improvement might be quite involved and can be
handled in a separate ticket.
was:
We need to ensure that abstract OM response class should NOT have
CleanupTableInfo annotation since the OM response subclass CleanupTableInfo
annotation values will override the parent CleanupTableInfo. The abstract class
@CleanupTableInfo will tempt contributors to exclude it in the CleanupTableInfo
of the subclasses. It is also difficult to keep track the inheritance if we
have more than one level of subclasses (e.g. OMKeyCreateResponseWithFSO extends
OMFileCreateResponseWithFSO extends OMFileCreateResponse)
Currently we have these abstract classes:
* AbstractS3MultipartAbortResponse
* AbstractOMKeyDeleteResponse
We can push the CleanupTableInfo of these abstract classes to the all the sub
concrete classes. After that we need to write a test to ensure that all the
concrete classes contain CleanupTableInfo and it contains all the
CleanupTableInfo of all the parent classes.
Ideally, CleanupTableInfo should be built by checking the
OMClientRequest#validateAndUpdateCache implementation for any cache update,
instead of hardcoding CleanupTableInfo in the OM response, which is very prone
to human error. However, this improvement might be quite involved and can be
handled in a separate ticket.
> Abstract OM response class should not be annotated with CleanupTableInfo
> ------------------------------------------------------------------------
>
> Key: HDDS-13362
> URL: https://issues.apache.org/jira/browse/HDDS-13362
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> We need to ensure that abstract OM response class should NOT have
> CleanupTableInfo annotation since the OM response subclass CleanupTableInfo
> annotation values will override the parent CleanupTableInfo. The abstract
> class @CleanupTableInfo will tempt contributors to exclude it in the
> CleanupTableInfo of the subclasses. It is also difficult to keep track the
> inheritance if we have more than one level of subclasses (e.g.
> OMKeyCreateResponseWithFSO extends OMFileCreateResponseWithFSO extends
> OMFileCreateResponse)
> Currently we have these abstract classes:
> * AbstractS3MultipartAbortResponse
> * AbstractOMKeyDeleteResponse
> We can push the CleanupTableInfo of these abstract classes to the all the sub
> concrete classes. After that we need to write a test to ensure that all the
> concrete classes contain CleanupTableInfo and it contains all the
> CleanupTableInfo of all the parent abstract classes.
> Ideally, CleanupTableInfo should be built by checking the
> OMClientRequest#validateAndUpdateCache implementation for any cache update,
> instead of hardcoding CleanupTableInfo in the OM response, which is very
> prone to human error. However, this improvement might be quite involved and
> can be handled in a separate ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@ozone.apache.org
For additional commands, e-mail: issues-h...@ozone.apache.org
