As discussed in#153,CursorIterator does not reflect the usual Java iterator idiom where anIterable is able to produce multipleIterator instances. This restriction exists because LMDB is used to provide the elements through an underlying transaction (provided at the timeDbi.iterate(..) is invoked) and cursor. Due to the use of these native resources, it is impractical to effectively produce multiple arbitraryIterators from the sameIterable, especially given eachIterator would need to be individuallyAutoCloseable to release its associated LMDB cursor.

It is difficult to envisage a practical use case for reusing anIterable in the first place, especially given the sharedTxn andKeyRange would result in the same the data for all returnedIterators anyway. Furthermore users with advanced needs are referred toDbi.openCursor(..), as this permits moving the cursor in any direction and at any time while theTxn remains available.

While#153 added a simple guard to prevent acquiring multipleIterator instances, the overall design remains non-idiomatic. FundamentallyDbi.iterate(..) should return a class that implementsIterable so that the returned object can be directly and idiomatically used in an enhancedfor statement. This would mean:

• RenamingCursorIterator toCursorIterable
• Implementing theIterable interface onCursorIterable
• Removing theIterator interface fromCursorIterable
• Relocating theIterator methods into the inner class returned fromCursorIterable.iterator()

Unfortunately these changes represent a minor breaking change for existing users. Given this is a breaking change, it's a good opportunity to remove the deprecatedIteratorType as well. TheIteratorType wasdeprecated in LmdbJava 0.6.0 (released July 2017) and represents the only deprecated code currently remaining in LmdbJava.