[jira] [Commented] (CASSANDRA-9975) Flatten RowIterator call hierarchy with a shared RowTransformer
[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14742053#comment-14742053
]
Aleksey Yeschenko commented on CASSANDRA-9975:
--
Relabeling as 3.0.x, as it's strictly speaking not rc-blocking, not
user-visible, and yet not too intrusive to put it into 3.0.0 final or even
3.0.1, worst case. Might still make it into rc1 however.
> 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.x
>
>
> 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)
[jira] [Commented] (CASSANDRA-9975) Flatten RowIterator call hierarchy with a shared RowTransformer
[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (CASSANDRA-9975) Flatten RowIterator call hierarchy with a shared RowTransformer
[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14729392#comment-14729392
]
Aleksey Yeschenko commented on CASSANDRA-9975:
--
Will do the first round of review before tomorrow morning. Will relabel back to
b2 if we end up committing in time, though.
> 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)
[jira] [Commented] (CASSANDRA-9975) Flatten RowIterator call hierarchy with a shared RowTransformer
[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712990#comment-14712990
]
Benedict commented on CASSANDRA-9975:
-
That little prod reminded me to rebase against latest. It's very little
changed. I've also added a follow up commit that cleans up the {{close}} method
based on the new {{Throwables}} functionality, and adds a handful of comments
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 beta 2
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)
[jira] [Commented] (CASSANDRA-9975) Flatten RowIterator call hierarchy with a shared RowTransformer
[
https://issues.apache.org/jira/browse/CASSANDRA-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712162#comment-14712162
]
Aleksey Yeschenko commented on CASSANDRA-9975:
--
[~iamaleksey] to review (:
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 beta 2
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)
