cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russ Hatch (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6438) Make user types keyspace scoped
Date Thu, 09 Jan 2014 18:22:53 GMT


Russ Hatch commented on CASSANDRA-6438:

I'm running into a snag traying to work with the new functionality.

My dtests now error out when I try to create a type without an active keyspace, which seems
reasonable to me (unless we want to allow the creation of user types outside any keyspace).

The problem I'm running into is I become disconnected from the node when trying to create
a user type within a keyspace:

Here's a setup that should replicate:
ccm create test_cluster
ccm populate -n 2
ccm start
ccm node1 cqlsh

cqlsh> create keyspace user_type_renaming with replication = {'class':'SimpleStrategy',
'replication_factor':2} ;
cqlsh> use user_type_renaming;
cqlsh:user_type_renaming> create type simple_type (user_number int);
TSocket read 0 bytes

Here's the exception found in the node's log:

ERROR [Thrift:1] 2014-01-09 11:14:57,996 - Error occurred
during processing of message.
java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to java.lang.String
	at org.apache.cassandra.serializers.AbstractTextSerializer.serialize(
	at org.apache.cassandra.db.marshal.AbstractType.decompose( ~[main/:na]
	at org.apache.cassandra.db.CFRowAdder.add( ~[main/:na]
	at org.apache.cassandra.db.CFRowAdder.addListEntry( ~[main/:na]
	at org.apache.cassandra.config.UTMetaData.toSchema( ~[main/:na]
	at org.apache.cassandra.config.UTMetaData.toSchema( ~[main/:na]
	at org.apache.cassandra.service.MigrationManager.announceNewType(
	at org.apache.cassandra.cql3.statements.CreateTypeStatement.announceMigration(
	at org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(
	at org.apache.cassandra.cql3.QueryProcessor.processStatement( ~[main/:na]
	at org.apache.cassandra.cql3.QueryProcessor.process( ~[main/:na]
	at org.apache.cassandra.cql3.QueryProcessor.process( ~[main/:na]
	at org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(
	at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(
	at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(
	at org.apache.thrift.ProcessFunction.process( ~[libthrift-0.9.1.jar:0.9.1]
	at org.apache.thrift.TBaseProcessor.process( ~[libthrift-0.9.1.jar:0.9.1]
	at org.apache.cassandra.thrift.CustomTThreadPoolServer$
	at java.util.concurrent.ThreadPoolExecutor.runWorker( [na:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$ [na:1.7.0_45]
	at [na:1.7.0_45]

> Make user types keyspace scoped
> -------------------------------
>                 Key: CASSANDRA-6438
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.1
>         Attachments: 6438.txt
> Currently, user types are declared at the top level. I wonder however if we might not
want to make them scoped to a given keyspace. It was not done in the initial patch for simplicity
and because I was not sure of the advantages of doing so. However, if we ever want to use
user types in system tables, having them scoped by keyspace means we won't have to care about
the new type conflicting with another existing type.
> Besides, having user types be part of a keyspace would allow for slightly more fine grained
permissions on them. 

This message was sent by Atlassian JIRA

View raw message