[
https://issues.apache.org/jira/browse/CASSANDRA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao updated CASSANDRA-95:
-----------------------------
Attachment: issue95.patchv3
Attached v3 of the patch.
Restored the multiGet APIs in StorageProxy and port them to the new ReadCommand
implementation.
Fix the class variable convention and naming.
Probably half of the code addition is from the duplicated license header (and
packages, etc) in the 5 new subclasses of ReadCommand. However, I think this
change will help us maintain the code better in the long run.
> 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, issue95.patchv3
>
>
> 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.
