[
https://issues.apache.org/jira/browse/TINKERPOP-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-2249:
----------------------------------------
Description:
{{RequestOptions}} provides a way to set certain control arguments to send to
the server like a per-request timeout or batch size. For bytecode traversals,
these are set somewhat statically and selectively by way of {{with()}} which
are then gathered by {{DriverRemoteConnection}} into a {{RequestOptions}}
object and then sent to the server on the request - it's basically leading to a
giant switch statement as new special options are being added.
Perhaps we should also consider a "request headers" space on the
{{RequestMessage}} rather than just throwing all these options in at the "args"
level.
Another idea might be to do {{with(TraversalSourceOptions)}} where
{{TraversalSourceOptions}} would be a new interface that something like
{{RequestOptions}} could implement. That way we could pass around
{{RequestOptions}} in a consistent way:
{code}
submit("g.V()", RequestOptions.build().timeout(100).create())
g.with(RequestOptions.build().timeout(100).create()).V()
{code}
rather than:
{code}
g.with("evaluationTimeout", 100)
{code}
was:
{{RequestOptions}} provides a way to set certain control arguments to send to
the server like a per-request timeout or batch size. For bytecode traversals,
these are set somewhat statically and selectively by way of {{with()}} which
are then gathered by {{DriverRemoteConnection}} into a {{RequestOptions}}
object and then sent to the server on the request - it's basically leading to a
giant switch statement as new special options are being added.
Perhaps we should also consider a "request headers" space on the
{{RequestMessage}} rather than just throwing all these options in at the "args"
level.
> Improve RequestOption passing
> -----------------------------
>
> Key: TINKERPOP-2249
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2249
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, server
> Affects Versions: 3.4.2
> Reporter: Stephen Mallette
> Priority: Major
>
> {{RequestOptions}} provides a way to set certain control arguments to send to
> the server like a per-request timeout or batch size. For bytecode traversals,
> these are set somewhat statically and selectively by way of {{with()}} which
> are then gathered by {{DriverRemoteConnection}} into a {{RequestOptions}}
> object and then sent to the server on the request - it's basically leading to
> a giant switch statement as new special options are being added.
> Perhaps we should also consider a "request headers" space on the
> {{RequestMessage}} rather than just throwing all these options in at the
> "args" level.
> Another idea might be to do {{with(TraversalSourceOptions)}} where
> {{TraversalSourceOptions}} would be a new interface that something like
> {{RequestOptions}} could implement. That way we could pass around
> {{RequestOptions}} in a consistent way:
> {code}
> submit("g.V()", RequestOptions.build().timeout(100).create())
> g.with(RequestOptions.build().timeout(100).create()).V()
> {code}
> rather than:
> {code}
> g.with("evaluationTimeout", 100)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
