[jira] [Updated] (TINKERPOP-2704) Traversal close() semantics

["Stephen Mallette (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stephen Mallette updated TINKERPOP-2704:
----------------------------------------
    Description: For 3.4.13/3.5.2 we added an explicit close state on a {{{}Traversal{}}}. It wasn't clear though if the close state should only apply to the root traversal. where as child traversals are anonymous and reused the root is not. so are child traversals really closeable? and what power does a {{reset()}} have in relation to a {{close()}} and this end state? also consider {{clone()}} and if the close state should be effectively be reset in that case (that is traditionally how that implementation has worked but it broke in 3.5.2/3.4.13 unfortunately).  (was: For 3.4.13/3.5.2 we added an explicit close state on a {{Traversal}}. It wasn't clear though if the close state should only apply to the root traversal. where as child traversals are anonymous and reused the root is not. so are child traversals really closeable? and what power does a {{reset()}} have in relation to a {{close()}} and this end state?)

> Traversal close() semantics
> ---------------------------
>
>                 Key: TINKERPOP-2704
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2704
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.5.2
>            Reporter: Stephen Mallette
>            Priority: Major
>
> For 3.4.13/3.5.2 we added an explicit close state on a {{{}Traversal{}}}. It wasn't clear though if the close state should only apply to the root traversal. where as child traversals are anonymous and reused the root is not. so are child traversals really closeable? and what power does a {{reset()}} have in relation to a {{close()}} and this end state? also consider {{clone()}} and if the close state should be effectively be reset in that case (that is traditionally how that implementation has worked but it broke in 3.5.2/3.4.13 unfortunately).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)