[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
