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

Sylvain Lebresne commented on CASSANDRA-4093:
---------------------------------------------

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

Hum, I though that parts of CASSANDRA-3680 was that say you have
{noformat}
CREATE TABLE t (
  rk text,
  k1 text,
  k2 text,
  c1 text,
  c2 text,
  PRIMARY KEY (rk, k1, k2)
);
{noformat}
then we could allow defining something like:
{noformat}
CREATE INDEX ON t(k1);
{noformat}
(or the same with k2).

Now truth is I haven't given a tons of though to this and if that is what you 
call partial indexes (it's not exactly the same than CASSANDRA-3782), then 
maybe it does have little convincing use cases. In which case, fair enough.

bq. for CQL users this is an implementation detail that they won't care about. 
And Thrift users can carry on with CT definitions to the degree they have or 
haven't previously

That's exactly what I meant :)

bq. Alternatively we could add a cql_column_metadata that supports the new 
semantics

Not necessarily against the idea but it feels like the integer makes for less 
special casing internally.

bq. Remove column_aliases and value_aliases from Thrift. They serve no purpose 
there than to give users a gun with which to shoot themselves in the foot

I'm good with that. There may just be 2 things to be careful with when doing 
that:
* we probably cannot assume just yet that no user will do a mix of access 
through thrift and through CQL. We must make sure one doesn't destroy the CQL 
metadata while doing a simple column family update from thrift. Shouldn't be 
too hard to do though.
* exposing everything through thrift have the slight advantage that a use may 
say set a column alias to allow transitioning to CQL3. There is likely better 
way to probide that though.

Anyway, I'll update the patch so that it doesn't expose those and 
component_index through thrift, and to not return ColumnDefinition when 
component_index is not null through thrift (so that the cli don't get confused).

                
> 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

        

Reply via email to