anchor.diff:  ++++
   endif::[]
   
  -With `apoc.periodic.iterate` you provide 2 statements, the *first* outer statement is providing a stream of values to be processed.
  -The *second*, inner statement processes *one* element at a time or with `iterateList:true` the whole batch at a time.
  +The `apoc.periodic.iterate` procedure is helpful when you need to handle large amounts of data for import, refactoring, and other cases that require large transactions.
  +It provides a way to batch the data by dividing the workload into two parts - a data-driven statement and an operations statement.
   
  -The results of the outer statement are passed into the inner statement as parameters, they are automatically made available with their names.
  +The data-driven statement is how you select what data needs handled.
  +You can provide a Cypher statement to select from existing graph data, read external data from a file or API, or retrieve data from another datastore.
  +The operations statement is what you want done to the selected data.
  +You can do things like execute Cypher for updating or creating/deleting the data or run other procedures to manipulate and transform values before loading.
  +
  +To run `apoc.periodic.iterate`, the data-driven statement is provided as the *first*, outer statement that results in a stream of values to be processed.
  +The operations statement is provided as the *second*, inner statement to process *one* element at a time or (with `iterateList:true`) a batch at a time.
  +The results of the outer statement are passed to the inner statement as parameters, so they are automatically made available with their names.
   
   .configuration options
   [options=header]
   |===
   | param | default | description
  -| batchSize | 1000 | that many inner statements are run within a single tx params: {_count, _batch}
  -| parallel | false | run inner statement in parallel, note that statements might deadlock
  -| retries | 0 | if the inner statement fails with an error, sleep 100ms and retry until retries-count is reached, param {_retry}
  -| iterateList | false | the inner statement is only executed once but the whole batchSize list is passed in as parameter {_batch}
  -| params | {} | externally passed in map of params
  -| concurrency | 50 | How many concurrent tasks are generate when using `parallel:true`
  -| failedParams | -1 | If set to a non-negative value, for each failed batch up to `failedParams` parameter sets are returned in in `yield failedParams`.
  +| batchSize | 10000 | run the specified number of inner statements in a single tx - params: {_count, _batch}
  +| parallel | false | run inner statements in parallel (note that statements might deadlock if conflicting)
  +| retries | 0 | if the inner statement fails with an error, sleep 100ms and retry until retries-count is reached - param {_retry}
  +| iterateList | true | execute inner statements once per batchSize (whole batchSize list is passed in as parameter {_batch})
  +| params | {} | externally pass in map of params
  +| concurrency | 50 | number of concurrent tasks are generated when using `parallel:true`
  +| failedParams | -1 | if set to a non-negative value, each failed batch up to `failedParams` parameter sets are returned in `yield failedParams`.
   |===
   
  -NOTE: We plan to make `iterateList:true` the default in upcoming releases, due to the automatic UNWINDing and providing of nested results as variables,
  -most queries should continue work.
  -
  -So if you were to add an `:Actor` label to several million `:Person` nodes, you would run:
  +.Examples
  +So, if you were to add an `:Actor` label to several million `:Person` nodes, you could run the following code:
   
   [source,cypher]
   ----
  
positive.code:   {batchSize:10000, parallel:true})
  ----
  
  Which would take 10k people from the stream and update them in a single transaction, executing the *second* statement for each person.
  
  Those executions can happen in parallel as updating node-labels or properties doesn't conflict.
  
  If you do more complex operations like updating or removing relationships, either *don't use parallel* OR make sure that you batch the work in a way that each subgraph of data is updated in one operation, e.g. by transferring the root objects.
  If you attempt complex operations, try to use e.g. `retries:3` to retry failed operations.
  
  [source,cypher]
  ----
  
negative.code:   {batchSize:100, parallel:true})
  ----
  
  In the above code, we select all the `Order` nodes that have an order date greater than `October 13, 2016` (first Cypher statement).
  Our configuration will batch those nodes into groups of 100 (`batchSize:100`) and run the batches in parallel for the second statement to process.
  The second Cypher statement takes those groups and finds the nodes that have a `HAS_ITEM` relationship to other nodes, then sums up the value of those items and sets that sum as a property (`o.value`) for the total order value.