[
https://issues.apache.org/jira/browse/CASSANDRA-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729336#action_12729336
]
Sandeep Tata commented on CASSANDRA-286:
----------------------------------------
I agree ... offset makes it hard to understand the cost of a get_slice. While
it is very convenient for pagination, dropping it from the API is probably the
right choice.
> slice offset breaks read repair
> -------------------------------
>
> Key: CASSANDRA-286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-286
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
>
> [code]
> int liveColumns = 0;
> int limit = offset + count;
> for (IColumn column : reducedColumns)
> {
> if (liveColumns >= limit)
> break;
> if (!finish.isEmpty()
> && ((isAscending && column.name().compareTo(finish) > 0))
> || (!isAscending && column.name().compareTo(finish) < 0))
> break;
> if (!column.isMarkedForDelete())
> liveColumns++;
> if (liveColumns > offset)
> returnCF.addColumn(column);
> }
> [code]
> The problem is that for offset to return the correct "live" columns, it has
> to ignore tombstones it scans before the first live one post-offset.
> This means that instead of being corrected within a few ms of a read, a node
> can continue returning deleted data indefinitely (until the next anti-entropy
> pass).
> Coupled with offset's inherent inefficiency (see CASSANDRA-261) I think this
> means we should take it out and leave offset to be computed client-side
> (which, for datasets under which it was reasonable server-side, will still be
> reasonable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
