stephen mallette created TINKERPOP-1589:
-------------------------------------------
Summary: 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)
