[ 
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict updated CASSANDRA-9975:
--------------------------------
    Attachment: before - schema query.png
                before - limit query.png
                after - schema query.png
                after - limit query.png

Aleksey suggested you may be looking for some screenshots of debug points for 
comparison. It's hard to convey the improved clarity, so I suggest you try 
debugging for yourself, but attached are a couple of example comparisons. 
They're not the most egregious, just easy to generate equivalents.

> 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
>
>         Attachments: after - limit query.png, after - schema query.png, 
> before - limit query.png, before - schema query.png
>
>
> 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)

Reply via email to