Closed hunoz closed 3 months ago
Can you try to bypass the validation with @suppress(["PaginatedTrait"])
and see if that would work for you?
Do you really need to make the token nested on input? It seems like a bad idea to me since if you ever wanted to support something like HTTP bindings, you couldn't use a GET request and put the token in the query string (those only support top-level members).
Can you try to bypass the validation with
@suppress(["PaginatedTrait"])
and see if that would work for you?
That seems to result in it failing to build with this error:
Projection source failed: java.util.NoSuchElementException: No value present
[java] java.util.NoSuchElementException: No value present
Do you really need to make the token nested on input? It seems like a bad idea to me since if you ever wanted to support something like HTTP bindings, you couldn't use a GET request and put the token in the query string (those only support top-level members).
Yes, we do this to group any current and future pagination attributes, since a request has other attributes. With this operation, we have no plan of supporting GET requests as the filters can get quite large.
Like Michael stated, it's a bad idea. Additionally, if we start adding support for nesting/pathing in more places, we'll get more requests to add it elsewhere (say, in the http traits).
Closing this as not planned.
Hello,
I have an operation with this request model:
and this response model:
and here is the Pagination structure:
I am trying to put the following
@paginated
trait in my operation:However, I am facing the following error:
I understand that this does not seem to be supported, however I would like this request to be seen as a feature request to allow me to use paths in
inputToken
andpageSize
.