[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14730571#comment-14730571
]
Benedict commented on CASSANDRA-9975:
-------------------------------------
I've pushed an update that fixes a problem with {{IllegalStateException}} being
thrown erroneously. I had previously provided {{UnfilteredRowFunction}} as the
default function type as I thought this would be easier, and provided
{{RowFunction}} as a convenience for clients that operated only an
{{RowIterator}} - however I forgot this myself, and used it for an
{{UnfilteredRowIterator}}, which it was rejecting as invalid.
Instead I've split {{UnfilteredRowFunction}} into {{RowFunction}} and
{{MarkerFunction}}, and rejected the latter in the constructor to a
{{TransfprmingRowIterator}}.
I've also reintroduced {{BTreeRow.isLive}} - not sure how that got removed -
and swapped the constructor argument order for {{TransformingIterator}} to
avoid class cast conflicts.
> Flatten RowIterator call hierarchy with a shared RowTransformer
> ---------------------------------------------------------------
>
> Key: CASSANDRA-9975
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9975
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0.0 rc1
>
>
> Stepping through a read response is made exceedingly difficult by the sheer
> depth of the call hierarchy, and how rapidly your context jumps around. This
> ticket intend to partially address that, by flattening one of the main causes
> of this: iterator transformations.
> I have a patch that attempts to mitigate (but not entirely eliminate) this,
> through the introduction of a {{RowTransformer}} class that all
> transformations are applied through. If a transformation has already been
> applied, the {{RowTransformer}} class does not wrap a new iterator, but
> instead returns a new {{RowTransformer}} that wraps the original underlying
> (untransformed) iterator and both transformations. This can accumulate an
> arbitrary number of transformations and, quite importantly, can apply the
> filtration step {{Unfiltered -> Row}} in the same instance as well. The
> intention being that a majority of control flow happens inside this
> {{RowTransformer}}, so there is far less context jumping to cope with.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
