[jira] [Commented] (TINKERPOP-1589) Re-Introduce CloseableIterator

["Paul Jackson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15795629#comment-15795629 ] 

Paul Jackson commented on TINKERPOP-1589:
-----------------------------------------

This all sounds good.

If you chose to make those methods return CloseableIterator, you could make it slightly easier for providers by giving CloseableIterator:
1) A default close() that does nothing, and
2) A static CloseableIterator<E> asCloseableIterator(Iterator<E> iterator) method that wraps the supplied Iterator with a default implementation (if the supplied iterator wasn't instanceof CloseableIterator).

> 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)