[
https://issues.apache.org/jira/browse/CASSANDRA-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729402#action_12729402
]
Jonathan Ellis edited comment on CASSANDRA-139 at 7/9/09 1:23 PM:
------------------------------------------------------------------
Michael Greene on IRC pointed out that you can make a case for keeping all
arguments the same to a slice call, with a list of keys. This appears to be
the direction Avinash was going over in CASSANDRA-70.
This makes sense if most of your ops are "I want to apply the same predicate
multiple times to different rows." Like a relational select. This would be
sufficiently general for the app I ported to Cassandra (which did after all
start on a rdbms).
The alternative is to be like the batch_insert api is and for each key allow a
different predicate. I can appreciate that argument from the standpoint of
symmetry, but it seems that in the common case it would make life a pain,
writing
predicate = ...
get_slice(table, [(key, predicate) for key in list_of_keys])
instead of just
get_slice(table, list_of_keys, predicate)
I think that Lesher's 10th law applies: "Premature optimization is the root of
all evil; premature generalization is premature optimization of the feature
list." Let's plan on following Avinash's lead on the multiget API, which means
that I'll pull both table and key out of the path structs shown in that patch.
was (Author: jbellis):
Michael Greene on IRC pointed out that you can make a case for keeping all
arguments the same to a slice call, with a list of keys. This appears to be
the direction Avinash was going over in CASSANDRA-70.
This makes sense if most of your ops are "I want to apply the same predicate
multiple times to different rows." Like a relational select. This would be
sufficiently general for the app I ported to Cassandra (which did after all
start on a rdbms).
The alternative is to be like the batch_insert api is and for each key allow a
different predicate. I can appreciate that argument from the standpoint of
symmetry, but it seems that in the common case it would make life a pain,
writing
predicate = ...
get_slice(table, [(key, predicate) for key in list_of_keys])
instead of just
get_slice(table, list_of_keys, predicate)
I think the principle that "Premature optimization is the root of all evil;
premature generalization is premature optimization of the feature list" applies
here.
Let's plan on following Avinash's lead on the multiget API, which means that
I'll pull both table and key out of the path structs shown in that patch.
> thrift API should use lists instead of colon-delimited strings to specify
> column path
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-139
> URL: https://issues.apache.org/jira/browse/CASSANDRA-139
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Attachments: 0001-thrift-changes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
