cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jun Rao (JIRA)" <>
Subject [jira] Updated: (CASSANDRA-95) clean up ReadCommand and related stuff for read repairs
Date Sat, 25 Apr 2009 01:12:30 GMT


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:
>             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.

View raw message