[jira] [Commented] (CASSANDRA-3025) PHP/PDO driver for Cassandra CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088333#comment-13088333 ] Mikko Koppanen commented on CASSANDRA-3025: --- Hi, well spotted. I am adding an updated version as attachment, which I believe fixes the issue. (full commit: https://github.com/mkoppanen/php-pdo_cassandra/commit/b12deac6a25bd09e3922ff5f05bfcd1d737a04c1) PHP/PDO driver for Cassandra CQL Key: CASSANDRA-3025 URL: https://issues.apache.org/jira/browse/CASSANDRA-3025 Project: Cassandra Issue Type: New Feature Components: API Reporter: Mikko Koppanen Labels: php Attachments: pdo_cassandra-0.1.0.tgz, php_test_results_20110818_2317.txt Hello, attached is the initial version of the PDO driver for Cassandra CQL language. This is a native PHP extension written in what I would call a combination of C and C++, due to PHP being C. The thrift API used is the C++. The API looks roughly following: {code} ?php $db = new PDO('cassandra:host=127.0.0.1;port=9160'); $db-exec (CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and strategy_options:replication_factor=1;); $db-exec (USE mytest); $db-exec (CREATE COLUMNFAMILY users ( my_key varchar PRIMARY KEY, full_name varchar );); $stmt = $db-prepare (INSERT INTO users (my_key, full_name) VALUES (:key, :full_name);); $stmt-execute (array (':key' = 'mikko', ':full_name' = 'Mikko K' )); {code} Currently prepared statements are emulated on the client side but I understand that there is a plan to add prepared statements to Cassandra CQL API as well. I will add this feature in to the extension as soon as they are implemented. Additional documentation can be found in github https://github.com/mkoppanen/php-pdo_cassandra, in the form of rendered MarkDown file. Tests are currently not included in the package file and they can be found in the github for now as well. I have created documentation in docbook format as well, but have not yet rendered it. Comments and feedback are welcome. Thanks, Mikko -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3025) PHP/PDO driver for Cassandra CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikko Koppanen updated CASSANDRA-3025: -- Attachment: pdo_cassandra-0.1.1.tgz Fixes issue with column counts PHP/PDO driver for Cassandra CQL Key: CASSANDRA-3025 URL: https://issues.apache.org/jira/browse/CASSANDRA-3025 Project: Cassandra Issue Type: New Feature Components: API Reporter: Mikko Koppanen Labels: php Attachments: pdo_cassandra-0.1.0.tgz, pdo_cassandra-0.1.1.tgz, php_test_results_20110818_2317.txt Hello, attached is the initial version of the PDO driver for Cassandra CQL language. This is a native PHP extension written in what I would call a combination of C and C++, due to PHP being C. The thrift API used is the C++. The API looks roughly following: {code} ?php $db = new PDO('cassandra:host=127.0.0.1;port=9160'); $db-exec (CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and strategy_options:replication_factor=1;); $db-exec (USE mytest); $db-exec (CREATE COLUMNFAMILY users ( my_key varchar PRIMARY KEY, full_name varchar );); $stmt = $db-prepare (INSERT INTO users (my_key, full_name) VALUES (:key, :full_name);); $stmt-execute (array (':key' = 'mikko', ':full_name' = 'Mikko K' )); {code} Currently prepared statements are emulated on the client side but I understand that there is a plan to add prepared statements to Cassandra CQL API as well. I will add this feature in to the extension as soon as they are implemented. Additional documentation can be found in github https://github.com/mkoppanen/php-pdo_cassandra, in the form of rendered MarkDown file. Tests are currently not included in the package file and they can be found in the github for now as well. I have created documentation in docbook format as well, but have not yet rendered it. Comments and feedback are welcome. Thanks, Mikko -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3003) Trunk single-pass streaming doesn't handle large row correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-3003: -- Attachment: mylyn-context.zip Trunk single-pass streaming doesn't handle large row correctly -- Key: CASSANDRA-3003 URL: https://issues.apache.org/jira/browse/CASSANDRA-3003 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Yuki Morishita Priority: Critical Labels: streaming Fix For: 1.0 Attachments: 3003-v1.txt, mylyn-context.zip For normal column family, trunk streaming always buffer the whole row into memory. In uses {noformat} ColumnFamily.serializer().deserializeColumns(in, cf, true, true); {noformat} on the input bytes. We must avoid this for rows that don't fit in the inMemoryLimit. Note that for regular column families, for a given row, there is actually no need to even recreate the bloom filter of column index, nor to deserialize the columns. It is enough to filter the key and row size to feed the index writer, but then simply dump the rest on disk directly. This would make streaming more efficient, avoid a lot of object creation and avoid the pitfall of big rows. Counters column family are unfortunately trickier, because each column needs to be deserialized (to mark them as 'fromRemote'). However, we don't need to do the double pass of LazilyCompactedRow for that. We can simply use a SSTableIdentityIterator and deserialize/reserialize input as it comes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3003) Trunk single-pass streaming doesn't handle large row correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088358#comment-13088358 ] Yuki Morishita commented on CASSANDRA-3003: --- Instead of creating CounterCleanedRow, I added appendFromStream method to SSTW, which handles both normal and counter column. I still need to work on SSTII because attached patch causes problem when iterating over cleaned up CounterColumns with 0-padding added during streaming. That also causes StreamingTransferTest fail. Will post update version soon. Trunk single-pass streaming doesn't handle large row correctly -- Key: CASSANDRA-3003 URL: https://issues.apache.org/jira/browse/CASSANDRA-3003 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Yuki Morishita Priority: Critical Labels: streaming Fix For: 1.0 Attachments: 3003-v1.txt, mylyn-context.zip For normal column family, trunk streaming always buffer the whole row into memory. In uses {noformat} ColumnFamily.serializer().deserializeColumns(in, cf, true, true); {noformat} on the input bytes. We must avoid this for rows that don't fit in the inMemoryLimit. Note that for regular column families, for a given row, there is actually no need to even recreate the bloom filter of column index, nor to deserialize the columns. It is enough to filter the key and row size to feed the index writer, but then simply dump the rest on disk directly. This would make streaming more efficient, avoid a lot of object creation and avoid the pitfall of big rows. Counters column family are unfortunately trickier, because each column needs to be deserialized (to mark them as 'fromRemote'). However, we don't need to do the double pass of LazilyCompactedRow for that. We can simply use a SSTableIdentityIterator and deserialize/reserialize input as it comes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3003) Trunk single-pass streaming doesn't handle large row correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-3003: -- Attachment: 3003-v1.txt Trunk single-pass streaming doesn't handle large row correctly -- Key: CASSANDRA-3003 URL: https://issues.apache.org/jira/browse/CASSANDRA-3003 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Yuki Morishita Priority: Critical Labels: streaming Fix For: 1.0 Attachments: 3003-v1.txt, mylyn-context.zip For normal column family, trunk streaming always buffer the whole row into memory. In uses {noformat} ColumnFamily.serializer().deserializeColumns(in, cf, true, true); {noformat} on the input bytes. We must avoid this for rows that don't fit in the inMemoryLimit. Note that for regular column families, for a given row, there is actually no need to even recreate the bloom filter of column index, nor to deserialize the columns. It is enough to filter the key and row size to feed the index writer, but then simply dump the rest on disk directly. This would make streaming more efficient, avoid a lot of object creation and avoid the pitfall of big rows. Counters column family are unfortunately trickier, because each column needs to be deserialized (to mark them as 'fromRemote'). However, we don't need to do the double pass of LazilyCompactedRow for that. We can simply use a SSTableIdentityIterator and deserialize/reserialize input as it comes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3003) Trunk single-pass streaming doesn't handle large row correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-3003: -- Attachment: (was: mylyn-context.zip) Trunk single-pass streaming doesn't handle large row correctly -- Key: CASSANDRA-3003 URL: https://issues.apache.org/jira/browse/CASSANDRA-3003 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.0 Reporter: Sylvain Lebresne Assignee: Yuki Morishita Priority: Critical Labels: streaming Fix For: 1.0 Attachments: 3003-v1.txt For normal column family, trunk streaming always buffer the whole row into memory. In uses {noformat} ColumnFamily.serializer().deserializeColumns(in, cf, true, true); {noformat} on the input bytes. We must avoid this for rows that don't fit in the inMemoryLimit. Note that for regular column families, for a given row, there is actually no need to even recreate the bloom filter of column index, nor to deserialize the columns. It is enough to filter the key and row size to feed the index writer, but then simply dump the rest on disk directly. This would make streaming more efficient, avoid a lot of object creation and avoid the pitfall of big rows. Counters column family are unfortunately trickier, because each column needs to be deserialized (to mark them as 'fromRemote'). However, we don't need to do the double pass of LazilyCompactedRow for that. We can simply use a SSTableIdentityIterator and deserialize/reserialize input as it comes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3001) Make the compression algorithm and chunk length configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088373#comment-13088373 ] Pavel Yaskevich commented on CASSANDRA-3001: Both patches need rebase. But from I can see everything is fine expect few minor things: - Is there a reason why code to copy compression parameters is duplicated all over the CFMetaData class even tho CompressionParameters have a static copyOptions method? Would be nice to make it public and reuse in CFMetaData. - Documentation for CLI and stress wasn't updated to list DeflateCompressor. Make the compression algorithm and chunk length configurable Key: CASSANDRA-3001 URL: https://issues.apache.org/jira/browse/CASSANDRA-3001 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: compression Fix For: 1.0 Attachments: 0001-Pluggable-algorithm-and-chunk-length.patch, 0002-Add-deflate-compressor.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3066) Creating a keyspace SYSTEM create issue
Creating a keyspace SYSTEM create issue --- Key: CASSANDRA-3066 URL: https://issues.apache.org/jira/browse/CASSANDRA-3066 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.4 Environment: Windows Reporter: Sébastien Giroux Priority: Minor Fix For: 0.8.5 It's possible to create a keyspace SYSTEM but impossible to do anything with it after. I know naming a keyspace SYSTEM is probably not a good idea but I was testing something on a test cluster and found this bug. Step to reproduce: connect localhost/9160; create keyspace SYSTEM; use SYSTEM; create column family test with comparator = UTF8Type and subcomparator = UTF8Type and default_validation_class = UTF8Type and column_metadata = [{column_name: title, validation_class: UTF8Type}, {column_name: publisher, validation_class: UTF8Type}]; And you get: system keyspace is not user-modifiable Although SYSTEM keyspace have been created and is a different keyspace as system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3066) Creating a keyspace SYSTEM cause issue
[ https://issues.apache.org/jira/browse/CASSANDRA-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Giroux updated CASSANDRA-3066: Summary: Creating a keyspace SYSTEM cause issue (was: Creating a keyspace SYSTEM create issue) Creating a keyspace SYSTEM cause issue -- Key: CASSANDRA-3066 URL: https://issues.apache.org/jira/browse/CASSANDRA-3066 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.4 Environment: Windows Reporter: Sébastien Giroux Priority: Minor Fix For: 0.8.5 It's possible to create a keyspace SYSTEM but impossible to do anything with it after. I know naming a keyspace SYSTEM is probably not a good idea but I was testing something on a test cluster and found this bug. Step to reproduce: connect localhost/9160; create keyspace SYSTEM; use SYSTEM; create column family test with comparator = UTF8Type and subcomparator = UTF8Type and default_validation_class = UTF8Type and column_metadata = [{column_name: title, validation_class: UTF8Type}, {column_name: publisher, validation_class: UTF8Type}]; And you get: system keyspace is not user-modifiable Although SYSTEM keyspace have been created and is a different keyspace as system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3052) CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Shaw updated CASSANDRA-3052: - Attachment: statement-improper-result.txt Patch checks to make sure the intended result is returned from the various {{execute}} method variants. CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement Key: CASSANDRA-3052 URL: https://issues.apache.org/jira/browse/CASSANDRA-3052 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.4 Reporter: Cathy Daw Labels: JDBC, cql Fix For: 0.8.5 Attachments: statement-improper-result.txt This test script used to work until I upgraded the jdbc driver to 1.0.4. *CQL 1.0.4*: apache-cassandra-cql-1.0.4-SNAPSHOT.jar build at revision 1158979 *Repro Script*: * drop in test directory, change package declaration and run: ant test -Dtest.name=resultSetNPE * The script gives you a NullPointerException when you uncomment out the following lines after a CREATE or INSERT statement. {code} colCount = res.getMetaData().getColumnCount(); res.next(); {code} * Please note that there is no need to comment out those lines if a SELECT statement was run prior. {code} package com.datastax.bugs; import java.sql.DriverManager; import java.sql.Connection; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import org.junit.Test; public class resultSetNPE { @Test public void createKS() throws Exception { Connection initConn = null; Connection connection = null; ResultSet res; Statement stmt; int colCount = 0; Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver); // Check create keyspace initConn = DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/default); stmt = initConn.createStatement(); try { System.out.println(Running DROP KS Statement); res = stmt.executeQuery(DROP KEYSPACE ks1); // res.next(); } catch (SQLException e) { if (e.getMessage().startsWith(Keyspace does not exist)) { // Do nothing - this just means you tried to drop something that was not there. // res = stmt.executeQuery(CREATE KEYSPACE ks1 with strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options:replication_factor=1); } } System.out.println(Running CREATE KS Statement); res = stmt.executeQuery(CREATE KEYSPACE ks1 with strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and strategy_options:replication_factor=1); // res.next(); initConn.close(); } @Test public void createCF() throws Exception { Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver); int colCount = 0; Connection connection = DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1); Statement stmt = connection.createStatement(); System.out.print(Running CREATE CF Statement); ResultSet res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY varchar PRIMARY KEY, password varchar, gender varchar, session_token varchar, state varchar, birth_year bigint)); //colCount = res.getMetaData().getColumnCount(); System.out.println( -- Column Count: + colCount); //res.next(); connection.close(); } @Test public void simpleSelect() throws Exception { Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver); int colCount = 0; Connection connection = DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1); Statement stmt = connection.createStatement(); System.out.print(Running INSERT Statement); ResultSet res = stmt.executeQuery(INSERT INTO users (KEY, password) VALUES ('user1', 'ch@nge')); //colCount = res.getMetaData().getColumnCount(); System.out.println( -- Column Count: + colCount); //res.next(); System.out.print(Running SELECT Statement); res = stmt.executeQuery(SELECT KEY, gender, state FROM users); colCount = res.getMetaData().getColumnCount(); System.out.println( -- Column Count: + colCount); res.getRow(); res.next(); connection.close(); } } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see:
[jira] [Updated] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
[ https://issues.apache.org/jira/browse/CASSANDRA-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Shaw updated CASSANDRA-2926: - Attachment: add-database-metadata-v1.txt Minimal support for JDBC Tooling. This Class will eventually provide the JDBC support for describing Column Families and Keyspaces. The JDBC Suite should provide a simple DatabaseMetaData implementation -- Key: CASSANDRA-2926 URL: https://issues.apache.org/jira/browse/CASSANDRA-2926 Project: Cassandra Issue Type: Sub-task Components: Drivers Affects Versions: 0.8.1 Reporter: Rick Shaw Assignee: Rick Shaw Priority: Minor Labels: CQL, JDBC Fix For: 0.8.5 Attachments: add-database-metadata-v1.txt The {{DatabaseMetaData}} interface provides access to meta-data information about the JDBC Driver implementation and the DB that it supports. This class would usually be used by tooling to discover the extended capabilities of the Driver Suite. A very basic implementation is planned initially. Non-static metadata about Keyspaces and Column Families can be provided in enhanced versions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3066) Creating a keyspace SYSTEM cause issue
[ https://issues.apache.org/jira/browse/CASSANDRA-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Giroux updated CASSANDRA-3066: Attachment: CASSANDRA-3066-0.8-v1.patch Creating a keyspace SYSTEM cause issue -- Key: CASSANDRA-3066 URL: https://issues.apache.org/jira/browse/CASSANDRA-3066 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.4 Environment: Windows Reporter: Sébastien Giroux Priority: Minor Fix For: 0.8.5 Attachments: CASSANDRA-3066-0.8-v1.patch It's possible to create a keyspace SYSTEM but impossible to do anything with it after. I know naming a keyspace SYSTEM is probably not a good idea but I was testing something on a test cluster and found this bug. Step to reproduce: connect localhost/9160; create keyspace SYSTEM; use SYSTEM; create column family test with comparator = UTF8Type and subcomparator = UTF8Type and default_validation_class = UTF8Type and column_metadata = [{column_name: title, validation_class: UTF8Type}, {column_name: publisher, validation_class: UTF8Type}]; And you get: system keyspace is not user-modifiable Although SYSTEM keyspace have been created and is a different keyspace as system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3066) Creating a keyspace SYSTEM cause issue
[ https://issues.apache.org/jira/browse/CASSANDRA-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088449#comment-13088449 ] Sébastien Giroux commented on CASSANDRA-3066: - If what we want is that the keyspace name is case-sensitive and system != SYSTEM, patch attached! Otherwise, I have no clue :) Creating a keyspace SYSTEM cause issue -- Key: CASSANDRA-3066 URL: https://issues.apache.org/jira/browse/CASSANDRA-3066 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.4 Environment: Windows Reporter: Sébastien Giroux Priority: Minor Fix For: 0.8.5 Attachments: CASSANDRA-3066-0.8-v1.patch It's possible to create a keyspace SYSTEM but impossible to do anything with it after. I know naming a keyspace SYSTEM is probably not a good idea but I was testing something on a test cluster and found this bug. Step to reproduce: connect localhost/9160; create keyspace SYSTEM; use SYSTEM; create column family test with comparator = UTF8Type and subcomparator = UTF8Type and default_validation_class = UTF8Type and column_metadata = [{column_name: title, validation_class: UTF8Type}, {column_name: publisher, validation_class: UTF8Type}]; And you get: system keyspace is not user-modifiable Although SYSTEM keyspace have been created and is a different keyspace as system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3066) Creating a keyspace SYSTEM cause issue
[ https://issues.apache.org/jira/browse/CASSANDRA-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088449#comment-13088449 ] Sébastien Giroux edited comment on CASSANDRA-3066 at 8/21/11 8:46 PM: -- If what we want is that the keyspace name is case-sensitive and system != SYSTEM, patch attached! Otherwise, I have no clue :) was (Author: wajam): If what we want is that the keyspace name is case-sensitive and system != SYSTEM, patch attached! Otherwise, I have no clue :) Creating a keyspace SYSTEM cause issue -- Key: CASSANDRA-3066 URL: https://issues.apache.org/jira/browse/CASSANDRA-3066 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.4 Environment: Windows Reporter: Sébastien Giroux Priority: Minor Fix For: 0.8.5 Attachments: CASSANDRA-3066-0.8-v1.patch It's possible to create a keyspace SYSTEM but impossible to do anything with it after. I know naming a keyspace SYSTEM is probably not a good idea but I was testing something on a test cluster and found this bug. Step to reproduce: connect localhost/9160; create keyspace SYSTEM; use SYSTEM; create column family test with comparator = UTF8Type and subcomparator = UTF8Type and default_validation_class = UTF8Type and column_metadata = [{column_name: title, validation_class: UTF8Type}, {column_name: publisher, validation_class: UTF8Type}]; And you get: system keyspace is not user-modifiable Although SYSTEM keyspace have been created and is a different keyspace as system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3066) Creating a keyspace SYSTEM cause issue
[ https://issues.apache.org/jira/browse/CASSANDRA-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088449#comment-13088449 ] Sébastien Giroux edited comment on CASSANDRA-3066 at 8/21/11 8:47 PM: -- If what we want is that the keyspace name is case-sensitive and system SYSTEM, patch attached! Otherwise, I have no clue :) was (Author: wajam): If what we want is that the keyspace name is case-sensitive and system != SYSTEM, patch attached! Otherwise, I have no clue :) Creating a keyspace SYSTEM cause issue -- Key: CASSANDRA-3066 URL: https://issues.apache.org/jira/browse/CASSANDRA-3066 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.4 Environment: Windows Reporter: Sébastien Giroux Priority: Minor Fix For: 0.8.5 Attachments: CASSANDRA-3066-0.8-v1.patch It's possible to create a keyspace SYSTEM but impossible to do anything with it after. I know naming a keyspace SYSTEM is probably not a good idea but I was testing something on a test cluster and found this bug. Step to reproduce: connect localhost/9160; create keyspace SYSTEM; use SYSTEM; create column family test with comparator = UTF8Type and subcomparator = UTF8Type and default_validation_class = UTF8Type and column_metadata = [{column_name: title, validation_class: UTF8Type}, {column_name: publisher, validation_class: UTF8Type}]; And you get: system keyspace is not user-modifiable Although SYSTEM keyspace have been created and is a different keyspace as system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira