[
https://issues.apache.org/jira/browse/JENA-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055102#comment-13055102
]
Andy Seaborne commented on JENA-76:
-----------------------------------
There is no requirement to implement Iterator.remove therefore the
renameResource is making an assumption that can't be relied on.
To implement Iterartor.remove in TDB is complex due to the fact there isn't a
triple table - only indexes that need co-ordination. An iterator is only
calculated over one index.
The solution is unlikely to introduce noticable additional work for TDB due to
cache effects. Also, when only a few statements are changed, it's only one
block. A delayed change solution may need spill-to-disk at scale. (See JENA-45)
The effects of requiring Iterator.remove on SDB are worse.
> Resourceutils.renameResource uses Iterator.remove() to make changes - not all
> iterators support .remove.
> --------------------------------------------------------------------------------------------------------
>
> Key: JENA-76
> URL: https://issues.apache.org/jira/browse/JENA-76
> Project: Jena
> Issue Type: Bug
> Components: Jena
> Reporter: Andy Seaborne
>
> Resourceutils.renameResource uses Iterator.remove() to make changes. TDB does
> not support Iterator.remove
> Instead, renameResource could grab a block (say, 1000) items, rename them and
> loop on blocks of 1000. This way, the iterator is terminated before updates
> are done. The nature of the rename operation means that the find iterator is
> executed until no resources are found so this batching mechanism does not
> need to need to track what has and has not been found - just repeat until
> less than 1000 items found.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
