[
https://issues.apache.org/jira/browse/CASSANDRA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702610#action_12702610
]
Jonathan Ellis commented on CASSANDRA-95:
-----------------------------------------
also: as much as I am a fan of removing unused code, avinash's last commit was
adding the multiget code to storageproxy and he does intend to expose that to
the client. we should port that to the new ReadCommand instead of deleting it.
stuff to satisfy my OCD that I'm perfectly happy to change myself pre-commit:
- in rewritten classes we should use normal variable names not the weird
underscore thing. Cassandra already had a mix of styles here so there is no
reason not to move towards normal conventions.
- using abbreviations (cfName) in local vars is fine; methods and class vars
though should spell out getColumnFamilyName, commandType, etc.
> clean up ReadCommand and related stuff for read repairs
> -------------------------------------------------------
>
> Key: CASSANDRA-95
> URL: https://issues.apache.org/jira/browse/CASSANDRA-95
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jun Rao
> Assignee: Jun Rao
> Attachments: issue95.patchv1, issue95.patchv2
>
>
> Today, ReadCommand doesn't have an explicit type attribute. A specific type
> of ReadCommand is determined based on subtle difference in parameters set.
> For example:
> if (start > 0 || (count > 0 && count < Integer.MAX_VALUE))
> {
> return table.getRow(key, columnFamilyColumn, start, count);
> }
> A get_slice ReadCommand is determined based on start and count values. This
> is very hard to understand. Also, code like that is duplicated in ReadCommand
> and ConsistencyManager.
> We need to make it easier to determine the type of a ReadCommand. This is
> necessary for code maintenance as well as supporting new APIs in the future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
