[
https://issues.apache.org/jira/browse/HDDS-15121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarveksha Yeshavantha Raju updated HDDS-15121:
----------------------------------------------
Description:
h1. Problem
The SCM list container API is split across multiple overloads, with each
variant adding another parameter for filtering.
h1. Drawbacks
* Does not scale with new filters - Adds more overloads, forces some filters
to exist only on one overload, so callers must pass unrelated parameters as
null / defaults.
* Duplicated javadoc - Each overload carries similar Javadoc.
h1. Solution
A *unified query object* (or single listContainers(proto) plus optional fields
on SCMListContainerRequestProto)
One server implementation that interprets that object, applies filters, applies
the cluster max-count cap, and returns a page.
New filters become new optional fields on the same request type - no new RPC
name, no new overload matrix.
was:
Unify SCM list container on {{SCMListContainerRequestProto}} so one message
carries paging and filters, and route client/server code through
{{ScmListContainerRequestCodec}} + {{ListContainerQuery}}.
Drop the old {{listContainer(long, …)}} overloads from
{{StorageContainerLocationProtocol}}, the client side PB translator, and
{{SCMClientProtocolServer}}; keep thin {{@Deprecated}} wrappers on
{{ScmClient}} / {{ContainerOperationClient}} that build the proto.
New list filters can be added as optional proto fields plus codec/server logic,
without new Java overloads on the core protocol.
> Unify SCM list container on SCMListContainerRequestProto
> --------------------------------------------------------
>
> Key: HDDS-15121
> URL: https://issues.apache.org/jira/browse/HDDS-15121
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Sarveksha Yeshavantha Raju
> Assignee: Sarveksha Yeshavantha Raju
> Priority: Major
>
> h1. Problem
> The SCM list container API is split across multiple overloads, with each
> variant adding another parameter for filtering.
> h1. Drawbacks
> * Does not scale with new filters - Adds more overloads, forces some filters
> to exist only on one overload, so callers must pass unrelated parameters as
> null / defaults.
>
> * Duplicated javadoc - Each overload carries similar Javadoc.
> h1. Solution
> A *unified query object* (or single listContainers(proto) plus optional
> fields on SCMListContainerRequestProto)
> One server implementation that interprets that object, applies filters,
> applies the cluster max-count cap, and returns a page.
> New filters become new optional fields on the same request type - no new RPC
> name, no new overload matrix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]