cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
Date Sat, 31 Mar 2012 14:54:25 GMT


Jonathan Ellis commented on CASSANDRA-4093:

bq. If you're referring to me saying that we could later consider allowing index on a full
composite in CQL3, then I'm sorry, let's forget about that for now. This patch does not force
us at all to do that.

My problem is that by supporting this misfeature from thrift in the name of backwards compatibility,
we're only pushing the problem into the future: the next step is for someone to say, "you
support this in Thrift, so I should be able to do it in CQL too."  I'd rather just draw a
line and say, "allowing this was a bad idea and we don't support it anymore."

bq. while it is true that we don't yet use that generalization

My point is that I'm pretty sure this is a generalization I don't want to support at all.
 This is a case where exposing every detail of your storage engine is a bad idea.

bq. Anyone that use an index on a CT currently won't be able to upgrade ever

The upgrade path requires some effort but is conceptually simple:

# update your application to no longer use the CT column index
# upgrade

(If you respond that updating your application is not acceptable, then why are you bothering
to upgrade?  Stay on the stable version that you built against in the first place, there is
nothing wrong with that.)

My claim is that inflicting this on a small handful of users (possibly as small as zero, and
I would bet money not more than one) is worth the upside of getting to a clean data model
in 1.2 without the distractions of legacy features like this.  The danger is that the longer
we preserve features like this, the more potential there is for new users to start using them
which makes it more difficult for us to drop them later.  So I'd rather make a clean break
now, than drag it out.

That said, if you are fundamentally opposed to not dropping any feature no matter how obscure
without some warning, which I admit is at least a consistent position, I would be okay with
supporting this in 1.1 with a clear intention to drop it in 1.2.  (Which would imply to me
that we leave the thrift interface alone.)  This would give us a full release to make sure
we have alternatives to whatever use cases people may have for the CT index (e.g. indexing
the sparse columns for the tag scenario).
> schema_* CFs do not respect column comparator which leads to CLI commands failure.
> ----------------------------------------------------------------------------------
>                 Key: CASSANDRA-4093
>                 URL:
>             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(;
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> 	at java.nio.Buffer.limit(
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getString(
> 	at org.apache.cassandra.cli.CliClient.describeColumnFamily(
> 	at org.apache.cassandra.cli.CliClient.describeKeySpace(
> 	at org.apache.cassandra.cli.CliClient.executeShowKeySpaces(
> (seen in trunk)

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message