[
https://issues.apache.org/jira/browse/TINKERPOP-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799280#comment-15799280
]
stephen mallette commented on TINKERPOP-1589:
---------------------------------------------
Those suggestions sound reasonable.
I think I will go back on some of the stuff I said above in the description. I
don't think we need to change the {{vertices()}} and {{edges()}} API for 3.3.0
anymore. The return types can probably just remain as {{Iterator}}. I don't
think there is much user confusion to avoid here as we don't encourage users
operating at the Graph Structure API level. Everything is done through the
Traversal API. Therefore, they wouldn't be calling those methods on {{Graph}}
in the first place.
> Re-Introduce CloseableIterator
> ------------------------------
>
> Key: TINKERPOP-1589
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1589
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
> Affects Versions: 3.2.3
> Reporter: stephen mallette
> Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> In Blueprints, we used to have {{CloseableIterable}}, which allowed users to
> release resources that might have been held by the underlying graph database.
> We didn't port that interface to TinkerPop 3.x for some reason. Graphs like
> OrientDB require a {{close()}} method for iterators returned from methods
> like {{Graph.vertices()}} and {{Graph.edges()}}. In addition, allowing
> {{close()}} from those iterators would make the {{close()}} on {{Traversal}}
> (non-remote) more useful and meaningful (right now it is an empty method by
> default).
> In Blueprints, {{Graph.getVertices()}} and {{Graph.getEdges()}} returned a
> {{Iterable}} and the Graph could choose to return {{CloseableIterator}}.
> Users who wanted to write provider agnostic code would then have to do:
> {code}
> if (iterable instanceof CloseableIterable))
> ((CloseableIterable) iterable).close();
> {code}
> I'm not sure why we didn't simply return {{CloseableIterable}} from those
> methods. Any reason we shouldn't do that now? Perhaps the approach is to
> introduce {{CloseableIterator}} to 3.2.4, but keep the return type of
> {{edges/vertices()}} as {{Iterator}} and then for 3.3.0 change the return
> type to {{CloseableIterator}}. In this way, the feature can be available in
> next release of 3.2.4 without any API changes and users can do the
> {{instanceof}} check above if they need to. Then for 3.3.0 when we allow API
> changes we can just make it more convenient with a {{CloseableIterator}}
> return type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
