[
https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593451#comment-13593451
]
Jonathan Ellis edited comment on CASSANDRA-3929 at 3/5/13 2:59 PM:
-------------------------------------------------------------------
bq. Let's ignore deletions first and let get ourselves in the feet of a user.
I think if we make users think about columns we have lost. It should really be
defined in terms of cql3 rows per partition.
I also think that it's confusing for a CF defined with a limit of, say, 50 to
have {{SELECT * FROM cf WHERE key = ?}} to sometimes return 50 results, but
sometimes more, depending on compaction state. We should have logic on the
query path to "pretend that compaction is perfect." Put another way, we
shouldn't leak implementation details. (And it should be fairly easy to do
this with the LIMIT logic.)
With this design I don't think we'd need any unusual restrictions on DELETE.
was (Author: jbellis):
bq. Let's ignore deletions first and let get ourselves in the feet of a
user.
I think if we make users think about columns we have lost. It should really be
defined in terms of cql3 rows per partition.
I also think that it's confusing for a CF defined with a limit of, say, 50 to
have {{SELECT * FROM cf WHERE key = ?}} to sometimes return 50 results, and
sometimes more, depending on compaction state. We should have logic on the
query path to "pretend that compaction is perfect." Put another way, we
shouldn't leak implementation details. (And it should be fairly easy to do
this with the LIMIT logic.)
> Support row size limits
> -----------------------
>
> Key: CASSANDRA-3929
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3929
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Dave Brosius
> Priority: Minor
> Labels: ponies
> Fix For: 2.0
>
> Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt,
> 3929_f.txt, 3929_g_tests.txt, 3929_g.txt, 3929.txt
>
>
> We currently support expiring columns by time-to-live; we've also had
> requests for keeping the most recent N columns in a row.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
