cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9975) Flatten RowIterator call hierarchy with a shared RowTransformer
Date Fri, 04 Sep 2015 09:44:45 GMT

    [ 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)

Mime
View raw message