cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-9975) Flatten Iterator call hierarchy with a shared Transformer
Date Fri, 23 Oct 2015 12:22:28 GMT


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:
>             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

View raw message