[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.

["Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-4093:
-------------------------------------------

bq. I'm not sure this will be so very confusing to users.

What I'm worried about is that it forces us to distinguish between "logical" and "physical" columns again.  I *love* that with CQL3 all I have to talk about is CQL columns and not have to dig out my diagrams of mapping CT to logical columns until someone starts to actually dig into the engine code.

bq. the introduction of composite_index (this patch) is just the first part CASSANDRA-3680. We will have to add it soon enough. It is hardly something added just for backward compatibility.

I don't follow at all.  3680 just means we want to be able to create an index on a logical column that is part of a CT under the hood: i.e., exactly the same thing we can already represent with the current-as-of-today CFMetadata.

I have virtually zero interest in supporting partial indexes as discussed in 3782; RDBMSes have shown pretty conclusively that this is a very niche feature.  Very much in the category of "let's take our time and add it if it makes sense, not just because we know how to do it."

bq. It's untrue that column_aliases and value_alias were 'added before we had cqlsh'. 

You left out key_alias, which is what I was referring to having added in 0.8 well before we had cqlsh.  I can only guess that we added column_aliases and value_aliases to thrift as well for the sake of consistency with that precedent.  As you point out, though, it's not too late to rip those out and we probably should.

bq. As soon as CASSANDRA-3680 is done, it will be usefull to allow creating secondary indexes on CT component on the thrift side. Why wouldn't we allow CASSANDRA-3680 on the thrift if it only cost us the addition of a simple int field in ColumnDef?

Sounds like you're getting a little ahead of yourself.  Why not add it as part of 3680, should that be something we want to do?  (But as I described above, I don't think it is.)
                
> schema_* CFs do not respect column comparator which leads to CLI commands failure.
> ----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-4093
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 1.1.0
>            Reporter: Dave Brosius
>            Assignee: Sylvain Lebresne
>             Fix For: 1.1.0
>
>         Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize schema_* CFs column_metadata do not respect CF comparator and use ByteBufferUtil.bytes(...) for column names which creates problems in CLI and probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> 	at java.nio.Buffer.limit(Buffer.java:247)
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> 	at org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> 	at org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> 	at org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira