You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2013/06/07 00:16:20 UTC

[jira] [Comment Edited] (CASSANDRA-5622) Update CqlRecordWriter to conform to RecordWriter API

    [ https://issues.apache.org/jira/browse/CASSANDRA-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677593#comment-13677593 ] 

Jonathan Ellis edited comment on CASSANDRA-5622 at 6/6/13 10:16 PM:
--------------------------------------------------------------------

Two solutions suggest themselves:
# Embrace ignoring of K and just pass new Object()
# Treat K as designed and accept responsibility for generating appropriate bind variables

I'm not a huge fan of #1 since it forces the user to do more work to generate bind variables for the PK values.  I'd rather automate that.

Let me give an example of what I mean in #2.  Suppose we have word counts as follows:
{code}
CREATE TABLE word_counts (
  file_name text,
  counted_at timestamp,
  word text,
  count int,
  PRIMARY KEY ((file_name, counted_at), word)
);
{code}

Then the user would configure CQL such as "UPDATE word_counts SET count = ?".  CqlRW would inspect the table definition and realize it needs to add " WHERE file_name = ? AND counted_at = ? AND word = ?".

Then when it gets a Map<String, BB> as K, it combines those with the List<BB> variables.  It knows the ordering of the pk columns since it generated it itself.

One downside: this doesn't lend itself to INSERT statements, since that does not separate SET/WHERE the way UPDATE does.  This is a limitation I can live with.
                
      was (Author: jbellis):
    Two solutions suggest themselves:
# Embrace ignoring of K and just pass new Object()
# Treat K as designed and accept responsibility for generating appropriate bind variables

I'm not a huge fan of #1 since it forces the user to do more work to generate bind variables for the PK values.  I'd rather automate that.

Let me give an example of what I mean in #2.  Suppose we have word counts as follows:
{code}
CREATE TABLE word_counts (
  file_name text,
  counted_at timestamp,
  word text,
  count int,
  PRIMARY KEY ((file_name, counted_at), word)
);
{code}

Then the user would configuer CQL such as "UPDATE word_counts SET count = ?".  CqlRW would inspect the table definition and realize it needs to add " WHERE file_name = ? AND counted_at = ? AND word = ?".

Then when it gets a Map<String, BB> as K, it combines those with the List<BB> variables.  It knows the ordering of the pk columns since it generated it itself.

One downside: this doesn't lend itself to INSERT statements, since that does not separate SET/WHERE the way UPDATE does.  This is a limitation I can live with.
                  
> Update CqlRecordWriter to conform to RecordWriter API
> -----------------------------------------------------
>
>                 Key: CASSANDRA-5622
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5622
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.2.6
>            Reporter: Jonathan Ellis
>            Assignee: Alex Liu
>             Fix For: 1.2.6
>
>
> {{RecordWriter<K, V>}} is supposed to write values V that can be uniquely identified by keys K.
> Currently CqlRW requires the user to give it all the bind variables for a complete statement in V, and effectively ignores K.

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