[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969381#comment-14969381
]
Benedict commented on CASSANDRA-9975:
-------------------------------------
bq. It may be better if the Transformer class grew into a package
More than happy to make that change. I agree there's a lot in there, especially
boilerplate (static methods etc), which might be easier to digest in smaller
chunks.
As for general complexity: this should just be taken as a first step, in my
book. There's a lot that can potentially be done in follow ups, but I didn't
want to eat the whole world. An imperfect first step is still a step in the
right direction. The interaction with counters, for instance, could be more
tightly coupled to perhaps reduce complexity wrt "stopping early". Possibly the
control flow can be simplified for the {{MoreContents}} work. There are many
avenues to follow, in fact.
My main goal here wasn't to make _this_ code simple (although I tried to make
it as good as I could personally manage in a reasonable time frame, given the
headline goal), but to make layers of the transformations themselves simple to
follow.
> Flatten Iterator call hierarchy with a shared Transformer
> ---------------------------------------------------------
>
> 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
>
>
> 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)
