[ 
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]

Reply via email to