date:20110824


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-3032:
--

Reviewer: xedin  (was: dbrosius)

 clean up KSMetadata, CFMetadata
 ---

 Key: CASSANDRA-3032
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3032
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Trivial
 Fix For: 1.0

 Attachments: 3032.txt


 There are too many conversion methods between Thrift and Avro and Native, 
 which is a potential source of bugs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1161137 - in /cassandra/branches/cassandra-0.8: ./ src/java/org/apache/cassandra/config/ src/java/org/apache/cassandra/db/ src/java/org/apache/cassandra/io/sstable/ src/java/org/apache/ca

Author: jbellis
Date: Wed Aug 24 14:55:17 2011
New Revision: 1161137

URL: http://svn.apache.org/viewvc?rev=1161137view=rev
Log:
allow sstable2json to work on index sstable files
patch by jbellis and tjake for CASSANDRA-3059

Modified:
cassandra/branches/cassandra-0.8/CHANGES.txt

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableReader.java

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/tools/SSTableExport.java

Modified: cassandra/branches/cassandra-0.8/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/CHANGES.txt?rev=1161137r1=1161136r2=1161137view=diff
==
--- cassandra/branches/cassandra-0.8/CHANGES.txt (original)
+++ cassandra/branches/cassandra-0.8/CHANGES.txt Wed Aug 24 14:55:17 2011
@@ -30,6 +30,7 @@
  * expose rpc timeouts per host in MessagingServiceMBean (CASSANDRA-2941)
  * avoid including cwd in classpath for deb and rpm packages (CASSANDRA-2881)
  * remove gossip state when a new IP takes over a token (CASSANDRA-3071)
+ * allow sstable2json to work on index sstable files (CASSANDRA-3059)
 
 
 0.8.4

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java?rev=1161137r1=1161136r2=1161137view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/config/CFMetaData.java
 Wed Aug 24 14:55:17 2011
@@ -945,6 +945,16 @@ public final class CFMetaData
 return column_metadata.get(name);
 }
 
+public ColumnDefinition getColumnDefinitionForIndex(String indexName)
+{
+for (ColumnDefinition def : column_metadata.values())
+{
+if (indexName.equals(def.getIndexName()))
+return def;
+}
+return null;
+}
+
 /**
  * Convert a null index_name to appropriate default name according to 
column status
  * @param cf_def Thrift ColumnFamily Definition

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java?rev=1161137r1=1161136r2=1161137view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
 Wed Aug 24 14:55:17 2011
@@ -309,11 +309,7 @@ public class ColumnFamilyStore implement
 assert info.getIndexType() != null;
 
 // create the index CFS
-IPartitioner rowPartitioner = StorageService.getPartitioner();
-AbstractType columnComparator = (rowPartitioner instanceof 
OrderPreservingPartitioner || rowPartitioner instanceof ByteOrderedPartitioner)
-? BytesType.instance
-: new 
LocalByPartionerType(StorageService.getPartitioner());
-final CFMetaData indexedCfMetadata = 
CFMetaData.newIndexMetadata(metadata, info, columnComparator);
+final CFMetaData indexedCfMetadata = 
CFMetaData.newIndexMetadata(metadata, info, indexComparator());
 ColumnFamilyStore indexedCfs = 
ColumnFamilyStore.createColumnFamilyStore(table,

  indexedCfMetadata.cfName,

  new 
LocalPartitioner(metadata.getColumn_metadata().get(info.name).getValidator()),
@@ -356,6 +352,14 @@ public class ColumnFamilyStore implement
 return f;
 }
 
+public static AbstractType indexComparator()
+{
+IPartitioner rowPartitioner = StorageService.getPartitioner();
+return (rowPartitioner instanceof OrderPreservingPartitioner || 
rowPartitioner instanceof ByteOrderedPartitioner)
+? BytesType.instance
+: new 
LocalByPartionerType(StorageService.getPartitioner());
+}
+
 public void buildSecondaryIndexes(CollectionSSTableReader sstables, 
SortedSetByteBuffer columns)
 {
 logger.info(String.format(Submitting index build of %s for data in 
%s,

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/io/sstable/SSTableReader.java
URL:

[jira] [Commented] (CASSANDRA-1608) Redesigned Compaction

[
https://issues.apache.org/jira/browse/CASSANDRA-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090275#comment-13090275
]

Jonathan Ellis commented on CASSANDRA-1608:
---

bq. I assumed that as I was doing operations on these SSTables in the
referenced views I would also need to use these referenced.

Right, but isn't that already the case pre-1608?

I'm just trying to understand if this fixes an existing bug, or if I'm missing
how the usage changed.

bq. Yes this is a potentially serious issue. This code gets called on every
read.

Feels like DataTracker is the wrong granularity to be doing reference counting
at. I'd like to see if we can push that into SSTableReader instead. But let's
do that in another ticket, for our purposes here correctness will suffice and
we can optimize later.

Redesigned Compaction
-

Key: CASSANDRA-1608
URL: https://issues.apache.org/jira/browse/CASSANDRA-1608
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Chris Goffinet
Assignee: Benjamin Coverston
Attachments: 1608-22082011.txt, 1608-v2.txt, 1608-v4.txt

After seeing the I/O issues in CASSANDRA-1470, I've been doing some more
thinking on this subject that I wanted to lay out.
I propose we redo the concept of how compaction works in Cassandra. At the
moment, compaction is kicked off based on a write access pattern, not read
access pattern. In most cases, you want the opposite. You want to be able to
track how well each SSTable is performing in the system. If we were to keep
statistics in-memory of each SSTable, prioritize them based on most accessed,
and bloom filter hit/miss ratios, we could intelligently group sstables that
are being read most often and schedule them for compaction. We could also
schedule lower priority maintenance on SSTable's not often accessed.
I also propose we limit the size of each SSTable to a fix sized, that gives
us the ability to better utilize our bloom filters in a predictable manner.
At the moment after a certain size, the bloom filters become less reliable.
This would also allow us to group data most accessed. Currently the size of
an SSTable can grow to a point where large portions of the data might not
actually be accessed as often.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3032) clean up KSMetadata, CFMetadata

2011-08-24 Thread Pavel Yaskevich (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090289#comment-13090289
 ] 

Pavel Yaskevich commented on CASSANDRA-3032:


Needs rebase

 clean up KSMetadata, CFMetadata
 ---

 Key: CASSANDRA-3032
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3032
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Trivial
 Fix For: 1.0

 Attachments: 3032.txt


 There are too many conversion methods between Thrift and Avro and Native, 
 which is a potential source of bugs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3032) clean up KSMetadata, CFMetadata


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-3032:
--

Attachment: 3032.txt

rebased

 clean up KSMetadata, CFMetadata
 ---

 Key: CASSANDRA-3032
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3032
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Trivial
 Fix For: 1.0

 Attachments: 3032.txt, 3032.txt


 There are too many conversion methods between Thrift and Avro and Native, 
 which is a potential source of bugs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1161167 - /cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/GCInspector.java

2011-08-24 Thread brandonwilliams

Author: brandonwilliams
Date: Wed Aug 24 15:46:05 2011
New Revision: 1161167

URL: http://svn.apache.org/viewvc?rev=1161167view=rev
Log:
Remove assertion causing test failures because GarbageCollectorMXBean sucks

Modified:

cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/GCInspector.java

Modified: 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/GCInspector.java
URL: 
http://svn.apache.org/viewvc/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/GCInspector.java?rev=1161167r1=1161166r2=1161167view=diff
==
--- 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/GCInspector.java
 (original)
+++ 
cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/GCInspector.java
 Wed Aug 24 15:46:05 2011
@@ -106,7 +106,6 @@ public class GCInspector
 if (previousCount == null)
 previousCount = 0L;
 gccounts.put(gc.getName(), count);
-assert count  previousCount;
 
 MemoryUsage mu = membean.getHeapMemoryUsage();
 long memoryUsed = mu.getUsed();

[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090304#comment-13090304
 ] 

Brandon Williams commented on CASSANDRA-3023:
-

bq. Will problem disappear after full upgrade to 0.8.4?

Yes.

 NPE in describe_ring
 

 Key: CASSANDRA-3023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.4
Reporter: Eric Falcao
Assignee: Brandon Williams
 Fix For: 0.8.5


 Not sure how much of the following is relevant besides the stack trace, but 
 here I go:
 I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't 
 restarted. I upgraded to 0.8.4 in the following fashion:
 -edited seeds
 -stopped both DC1 nodes
 -upgraded jars
 -started both nodes at the same time
 The non-seed node came up first and showed the following error. Then when the 
 seed node came up, the error went away on the non-seed node but started 
 occurring on the seed node:
 ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) 
 Internal error processing describe_ring
 java.lang.NullPointerException
   at 
 org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623)
   at 
 org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664)
   at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3010) Java CQL command-line shell


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090310#comment-13090310
 ] 

Jonathan Ellis commented on CASSANDRA-3010:
---

There's actually a more meaningful reason why avoiding extra dependencies is a 
good thing: the most popular dev platform remains Windows, where dependency 
management remains firmly in the dark ages.

It's kind of a black eye for the new-user experience if Joe Windows tries to 
follow the README and try some sample CQL, but it doesn't work until he goes 
and installs Python first.

 Java CQL command-line shell
 ---

 Key: CASSANDRA-3010
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3010
 Project: Cassandra
  Issue Type: New Feature
  Components: Tools
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
 Fix For: 1.0


 We need a real CQL shell that:
 - does not require installing additional environments
 - includes show keyspaces and other introspection tools
 - does not break existing cli scripts
 I.e., it needs to be java, but it should be a new tool instead of replacing 
 the existing cli.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-3023) NPE in describe_ring


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-3023:


Attachment: 3023.txt

bq. I think return half-broken data is the right solution, since pre-1777 
clients aren't going to be looking for the new data anyway.

You're right, but it sure bothers my OCD :)

Trivial patch attached.

 NPE in describe_ring
 

 Key: CASSANDRA-3023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.4
Reporter: Eric Falcao
Assignee: Brandon Williams
 Fix For: 0.8.5

 Attachments: 3023.txt


 Not sure how much of the following is relevant besides the stack trace, but 
 here I go:
 I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't 
 restarted. I upgraded to 0.8.4 in the following fashion:
 -edited seeds
 -stopped both DC1 nodes
 -upgraded jars
 -started both nodes at the same time
 The non-seed node came up first and showed the following error. Then when the 
 seed node came up, the error went away on the non-seed node but started 
 occurring on the seed node:
 ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) 
 Internal error processing describe_ring
 java.lang.NullPointerException
   at 
 org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623)
   at 
 org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664)
   at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090321#comment-13090321
 ] 

Jonathan Ellis commented on CASSANDRA-3023:
---

+1

 NPE in describe_ring
 

 Key: CASSANDRA-3023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.4
Reporter: Eric Falcao
Assignee: Brandon Williams
 Fix For: 0.8.5

 Attachments: 3023.txt


 Not sure how much of the following is relevant besides the stack trace, but 
 here I go:
 I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't 
 restarted. I upgraded to 0.8.4 in the following fashion:
 -edited seeds
 -stopped both DC1 nodes
 -upgraded jars
 -started both nodes at the same time
 The non-seed node came up first and showed the following error. Then when the 
 seed node came up, the error went away on the non-seed node but started 
 occurring on the seed node:
 ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) 
 Internal error processing describe_ring
 java.lang.NullPointerException
   at 
 org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623)
   at 
 org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664)
   at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2810) RuntimeException in Pig when using dump command on column name


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-2810:


Reviewer: jeromatron

 RuntimeException in Pig when using dump command on column name
 

 Key: CASSANDRA-2810
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2810
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8.1
 Environment: Ubuntu 10.10, 32 bits
 java version 1.6.0_24
 Brisk beta-2 installed from Debian packages
Reporter: Silvère Lestang
Assignee: Brandon Williams
 Attachments: 2810-v2.txt, 2810-v3.txt, 2810.txt


 This bug was previously report on [Brisk bug 
 tracker|https://datastax.jira.com/browse/BRISK-232].
 In cassandra-cli:
 {code}
 [default@unknown] create keyspace Test
 with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
 and strategy_options = [{replication_factor:1}];
 [default@unknown] use Test;
 Authenticated to keyspace: Test
 [default@Test] create column family test;
 [default@Test] set test[ascii('row1')][long(1)]=integer(35);
 set test[ascii('row1')][long(2)]=integer(36);
 set test[ascii('row1')][long(3)]=integer(38);
 set test[ascii('row2')][long(1)]=integer(45);
 set test[ascii('row2')][long(2)]=integer(42);
 set test[ascii('row2')][long(3)]=integer(33);
 [default@Test] list test;
 Using default limit of 100
 ---
 RowKey: 726f7731
 = (column=0001, value=35, timestamp=1308744931122000)
 = (column=0002, value=36, timestamp=1308744931124000)
 = (column=0003, value=38, timestamp=1308744931125000)
 ---
 RowKey: 726f7732
 = (column=0001, value=45, timestamp=1308744931127000)
 = (column=0002, value=42, timestamp=1308744931128000)
 = (column=0003, value=33, timestamp=1308744932722000)
 2 Rows Returned.
 [default@Test] describe keyspace;
 Keyspace: Test:
   Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
   Durable Writes: true
 Options: [replication_factor:1]
   Column Families:
 ColumnFamily: test
   Key Validation Class: org.apache.cassandra.db.marshal.BytesType
   Default column value validator: 
 org.apache.cassandra.db.marshal.BytesType
   Columns sorted by: org.apache.cassandra.db.marshal.BytesType
   Row cache size / save period in seconds: 0.0/0
   Key cache size / save period in seconds: 20.0/14400
   Memtable thresholds: 0.571875/122/1440 (millions of ops/MB/minutes)
   GC grace seconds: 864000
   Compaction min/max thresholds: 4/32
   Read repair chance: 1.0
   Replicate on write: false
   Built indexes: []
 {code}
 In Pig command line:
 {code}
 grunt test = LOAD 'cassandra://Test/test' USING CassandraStorage() AS 
 (rowkey:chararray, columns: bag {T: (name:long, value:int)});
 grunt value_test = foreach test generate rowkey, columns.name, columns.value;
 grunt dump value_test;
 {code}
 In /var/log/cassandra/system.log, I have severals time this exception:
 {code}
 INFO [IPC Server handler 3 on 8012] 2011-06-22 15:03:28,533 
 TaskInProgress.java (line 551) Error from 
 attempt_201106210955_0051_m_00_3: java.lang.RuntimeException: Unexpected 
 data type -1 found in stream.
   at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:478)
   at org.apache.pig.data.BinInterSedes.writeTuple(BinInterSedes.java:541)
   at org.apache.pig.data.BinInterSedes.writeBag(BinInterSedes.java:522)
   at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:361)
   at org.apache.pig.data.BinInterSedes.writeTuple(BinInterSedes.java:541)
   at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:357)
   at 
 org.apache.pig.impl.io.InterRecordWriter.write(InterRecordWriter.java:73)
   at org.apache.pig.impl.io.InterStorage.putNext(InterStorage.java:87)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigOutputFormat$PigRecordWriter.write(PigOutputFormat.java:138)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigOutputFormat$PigRecordWriter.write(PigOutputFormat.java:97)
   at 
 org.apache.hadoop.mapred.MapTask$NewDirectOutputCollector.write(MapTask.java:638)
   at 
 org.apache.hadoop.mapreduce.TaskInputOutputContext.write(TaskInputOutputContext.java:80)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapOnly$Map.collect(PigMapOnly.java:48)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.runPipeline(PigMapBase.java:239)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:232)
   at

[jira] [Updated] (CASSANDRA-2855) Skip rows with empty columns when slicing entire row

[
https://issues.apache.org/jira/browse/CASSANDRA-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brandon Williams updated CASSANDRA-2855:

Attachment: 2855-v5.txt

v5 removes the skip.empty.rows option making this behavior always-on.

Skip rows with empty columns when slicing entire row

Key: CASSANDRA-2855
URL: https://issues.apache.org/jira/browse/CASSANDRA-2855
Project: Cassandra
Issue Type: Improvement
Components: API
Reporter: Jeremy Hanna
Assignee: Jeremy Hanna
Priority: Minor
Labels: hadoop
Fix For: 0.8.5

Attachments: 2855-v2.txt, 2855-v3.txt, 2855-v4.txt, 2855-v5.txt

We have been finding that range ghosts appear in results from Hadoop via Pig.
This could also happen if rows don't have data for the slice predicate that
is given. This leads to having to do a painful amount of defensive checking
on the Pig side, especially in the case of range ghosts.
We would like to add an option to skip rows that have no column values in it.
That functionality existed before in core Cassandra but was removed because
of the performance penalty of that checking. However with Hadoop support in
the RecordReader, that is batch oriented anyway, so individual row reading
performance isn't as much of an issue. Also we would make it an optional
config parameter for each job anyway, so people wouldn't have to incur that
penalty if they are confident that there won't be those empty rows or they
don't care.
It could be parameter cassandra.skip.empty.rows and be true/false.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CASSANDRA-2954) Lack of conversion from Cassandra's TimeUUIDType to any compatible type in Pig.


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams resolved CASSANDRA-2954.
-

Resolution: Duplicate

CASSANDRA-2810 will solve this.

 Lack of conversion from Cassandra's TimeUUIDType to any compatible type in 
 Pig.
 ---

 Key: CASSANDRA-2954
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2954
 Project: Cassandra
  Issue Type: Bug
  Components: Hadoop
Reporter: Jacek Gerbszt
Priority: Minor
 Fix For: 0.8.5


 CassandraStorage passes wrong data types to pig. When I try to access column 
 family with comparator=TimeUUIDType, I get an exception:
 java.lang.RuntimeException: Unexpected data type -1 found in stream.
   at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:478)
   at org.apache.pig.data.BinInterSedes.writeTuple(BinInterSedes.java:541)
   at org.apache.pig.data.BinInterSedes.writeBag(BinInterSedes.java:522)
   at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:361)
   at org.apache.pig.data.BinInterSedes.writeTuple(BinInterSedes.java:541)
   at org.apache.pig.data.BinInterSedes.writeDatum(BinInterSedes.java:357)
   at 
 org.apache.pig.impl.io.InterRecordWriter.write(InterRecordWriter.java:73)
   at org.apache.pig.impl.io.InterStorage.putNext(InterStorage.java:87)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigOutputFormat$PigRecordWriter.write(PigOutputFormat.java:138)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigOutputFormat$PigRecordWriter.write(PigOutputFormat.java:97)
   at 
 org.apache.hadoop.mapred.MapTask$NewDirectOutputCollector.write(MapTask.java:531)
   at 
 org.apache.hadoop.mapreduce.TaskInputOutputContext.write(TaskInputOutputContext.java:80)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapOnly$Map.collect(PigMapOnly.java:48)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.runPipeline(PigMapBase.java:239)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:232)
   at 
 org.apache.pig.backend.hadoop.executionengine.mapReduceLayer.PigMapBase.map(PigMapBase.java:53)
   at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:144)
   at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:647)
   at org.apache.hadoop.mapred.MapTask.run(MapTask.java:323)
   at 
 org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:210)
 The reason is that CassandraStorage converts TimeUUIDType to UUID using 
 org.apache.cassandra.db.marshal.TimeUUIDType and puts it in a Pig's Tuple:
 CassandraStorage.java:148:pair.set(0, 
 marshallers.get(0).compose(name));
 Pig cannot handle UUID, so throws an exception.
 There's a need for some mechanizm to convert Cassadra types to Pig types, 
 because probably this isn't a single case.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3032) clean up KSMetadata, CFMetadata

2011-08-24 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090358#comment-13090358
 ] 

Hudson commented on CASSANDRA-3032:
---

Integrated in Cassandra-0.8 #293 (See 
[https://builds.apache.org/job/Cassandra-0.8/293/])
Fix NPE in describe_ring with a mixed cluster.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-3032

brandonwilliams : 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1161189
Files : 
* 
/cassandra/branches/cassandra-0.8/src/java/org/apache/cassandra/service/StorageService.java


 clean up KSMetadata, CFMetadata
 ---

 Key: CASSANDRA-3032
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3032
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Trivial
 Fix For: 1.0

 Attachments: 3032.txt, 3032.txt


 There are too many conversion methods between Thrift and Avro and Native, 
 which is a potential source of bugs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1161216 - in /cassandra/trunk: ./ contrib/ drivers/ drivers/java/ interface/thrift/gen-java/org/apache/cassandra/thrift/

Author: jbellis
Date: Wed Aug 24 18:18:52 2011
New Revision: 1161216

URL: http://svn.apache.org/viewvc?rev=1161216view=rev
Log:
move drivers back in-tree until build issues can be fixed.  see CASSANDRA-2761

Added:
cassandra/trunk/drivers/
  - copied from r1161213, cassandra/drivers/
Removed:
cassandra/trunk/drivers/java/README.txt
cassandra/trunk/drivers/java/build.properties.default
cassandra/trunk/drivers/java/build.xml
Modified:
cassandra/trunk/   (props changed)
cassandra/trunk/build.xml
cassandra/trunk/contrib/   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java
   (props changed)

cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java
   (props changed)

Propchange: cassandra/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Aug 24 18:18:52 2011
@@ -1,7 +1,7 @@
 
/cassandra/branches/cassandra-0.6:922689-1052356,1052358-1053452,1053454,1053456-1131291
 /cassandra/branches/cassandra-0.7:1026516-1160444,1160825
 /cassandra/branches/cassandra-0.7.0:1053690-1055654
-/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1160459,1160827
+/cassandra/branches/cassandra-0.8:1090934-1125013,1125019-1133844,1133846-1133917,1133919-1135156,1135158-1160459,1160827
 /cassandra/branches/cassandra-0.8.0:1125021-1130369
 /cassandra/branches/cassandra-0.8.1:1101014-1125018
 /cassandra/tags/cassandra-0.7.0-rc3:1051699-1053689

Modified: cassandra/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/build.xml?rev=1161216r1=1161215r2=1161216view=diff
==
--- cassandra/trunk/build.xml (original)
+++ cassandra/trunk/build.xml Wed Aug 24 18:18:52 2011
@@ -36,6 +36,7 @@
 property name=build.src value=${basedir}/src/
 property name=build.src.java value=${basedir}/src/java/
 property name=build.src.resources value=${basedir}/src/resources/
+property name=build.src.driver value=${basedir}/drivers/java/src /
 property name=avro.src value=${basedir}/src/avro/
 property name=build.src.gen-java value=${basedir}/src/gen-java/
 property name=build.lib value=${basedir}/lib/
@@ -45,6 +46,7 @@
 property name=build.classes value=${build.dir}/classes/
 property name=build.classes.main value=${build.classes}/main /
 property name=build.classes.thrift value=${build.classes}/thrift /
+property name=build.classes.cql value=${build.classes}/cql /
 property name=javadoc.dir value=${build.dir}/javadoc/
 property name=javadoc.jars.dir value=${build.dir}/javadocs/
 property name=interface.dir value=${basedir}/interface/
@@ -58,9 +60,11 @@
 property name=test.data value=${test.dir}/data/
 property name=test.name value=*Test/
 property name=test.unit.src value=${test.dir}/unit/
+property name=test.src.driver value=${basedir}/drivers/java/test/
 property name=test.long.src value=${test.dir}/long/
 property name=test.distributed.src value=${test.dir}/distributed/
 property name=dist.dir value=${build.dir}/dist/
+property name=cql.driver.version value=1.0.4 /
 condition property=version value=${base.version}
   isset property=release/
 /condition
@@ -157,6 +161,7 @@
 message=Not a source artifact, stopping here. /
 mkdir dir=${build.classes.main}/
 mkdir dir=${build.classes.thrift}/
+mkdir dir=${build.classes.cql}/
 mkdir dir=${test.lib}/
 mkdir dir=${test.classes}/
 mkdir dir=${build.src.gen-java}/
@@ -391,6 +396,7 @@ url=${svn.entry.url}?pathrev=${svn.entry
   dependency groupId=log4j artifactId=log4j version=1.2.16 /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-all version=${version} /
   dependency groupId=org.apache.cassandra 
artifactId=cassandra-thrift version=${version} /
+  dependency groupId=org.apache.cassandra 
artifactId=cassandra-cql version=${version} /
 /dependencyManagement
 developer id=alakshman name=Avinash Lakshman/
 developer id=antelder name=Anthony Elder/
@@ -478,7 +484,7 @@ url=${svn.entry.url}?pathrev=${svn.entry
 
 !-- don't need hadoop classes to run, but if you use the hadoop stuff 
--
 dependency groupId=org.apache.hadoop artifactId=hadoop-core 
optional=true/
-
+
 !-- don't need jna to run, but nice to have --
 dependency groupId=net.java.dev.jna artifactId=jna 
optional=true/
 
@@ -497,6 +503,22

svn commit: r1161217 - /cassandra/drivers/

Author: jbellis
Date: Wed Aug 24 18:19:28 2011
New Revision: 1161217

URL: http://svn.apache.org/viewvc?rev=1161217view=rev
Log:
move drivers back in-tree until build issues can be fixed.  see CASSANDRA-2761

Removed:
cassandra/drivers/

buildbot failure in ASF Buildbot on cassandra-trunk

2011-08-24 Thread buildbot

The Buildbot has detected a new failure on builder cassandra-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/1549

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: isis_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch cassandra/trunk] 1161216
Blamelist: jbellis

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090383#comment-13090383
]

Jonathan Ellis commented on CASSANDRA-2761:
---

bq. I also realize that there is more work needed here to decouple the JDBC
driver and make this all work better, work that I've volunteered to do. I
haven't had as much time to spend on this lately, but that should be changing
RSN.

It's been another two weeks and we're still in this no-man's land where git
can't see drivers, the jdbc build is a big TODO, and anything that depends on
jdbc like 3010 is basically SOL.

Again, I'm not against purity, but it's clear that the original breaking out of
drivers/ was done prematurely (was there even a Jira ticket with a patch? It
looks like we went from that's a good idea on -dev to ripping apart svn).
I've reverted things until the breakout can be done properly.

JDBC driver does not build
--

Key: CASSANDRA-2761
URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
Fix For: 1.0

Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt

Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1161221 - /cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/EmbeddedServiceBase.java

Author: jbellis
Date: Wed Aug 24 18:30:29 2011
New Revision: 1161221

URL: http://svn.apache.org/viewvc?rev=1161221view=rev
Log:
update for CFMetaData - Schema refactor

Modified:

cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/EmbeddedServiceBase.java

Modified: 
cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/EmbeddedServiceBase.java
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/EmbeddedServiceBase.java?rev=1161221r1=1161220r2=1161221view=diff
==
--- 
cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/EmbeddedServiceBase.java
 (original)
+++ 
cassandra/trunk/drivers/java/test/org/apache/cassandra/cql/EmbeddedServiceBase.java
 Wed Aug 24 18:30:29 2011
@@ -27,10 +27,7 @@ import java.net.UnknownHostException;
 
 import org.apache.cassandra.CleanupHelper;
 import org.apache.cassandra.SchemaLoader;
-import org.apache.cassandra.config.CFMetaData;
-import org.apache.cassandra.config.ConfigurationException;
-import org.apache.cassandra.config.DatabaseDescriptor;
-import org.apache.cassandra.config.KSMetaData;
+import org.apache.cassandra.config.*;
 import org.apache.cassandra.service.EmbeddedCassandraService;
 import org.junit.BeforeClass;
 
@@ -39,10 +36,9 @@ import org.junit.BeforeClass;
  */
 public abstract class EmbeddedServiceBase
 {
-
 /** The embedded server cassandra. */
 private static EmbeddedCassandraService cassandra;
-
+
 @BeforeClass 
 public static void cleanUpOldStuff() throws IOException
 {
@@ -77,9 +73,9 @@ public abstract class EmbeddedServiceBas
 {
 for (CFMetaData cfm : table.cfMetaData().values())
 {
-CFMetaData.map(cfm);
+Schema.instance.load(cfm);
 }
-DatabaseDescriptor.setTableDefinition(table, 
DatabaseDescriptor.getDefsVersion());
+Schema.instance.setTableDefinition(table, 
Schema.instance.getVersion());
 }
 }
 /**

buildbot success in ASF Buildbot on cassandra-trunk

2011-08-24 Thread buildbot

The Buildbot has detected a restored build on builder cassandra-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/cassandra-trunk/builds/1550

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: isis_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch cassandra/trunk] 1161221
Blamelist: jbellis

Build succeeded!

sincerely,
 -The Buildbot

[jira] [Commented] (CASSANDRA-3032) clean up KSMetadata, CFMetadata

2011-08-24 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090418#comment-13090418
 ] 

Hudson commented on CASSANDRA-3032:
---

Integrated in Cassandra #1045 (See 
[https://builds.apache.org/job/Cassandra/1045/])
Clean up KSMetadata, CFMetadata from unnecessary Thrift-Avro conversion 
methods
patch by Jonathan Ellis and Pavel Yaskevich; reviewed by Pavel Yaskevich for 
CASSANDRA-3032

xedin : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1161230
Files : 
* 
/cassandra/trunk/test/unit/org/apache/cassandra/config/DatabaseDescriptorTest.java
* 
/cassandra/trunk/test/unit/org/apache/cassandra/config/ColumnDefinitionTest.java
* /cassandra/trunk/src/java/org/apache/cassandra/config/ColumnDefinition.java
* /cassandra/trunk/src/java/org/apache/cassandra/cql/DropIndexStatement.java
* 
/cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateColumnFamily.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/migration/Migration.java
* /cassandra/trunk/src/java/org/apache/cassandra/cql/QueryProcessor.java
* /cassandra/trunk/src/java/org/apache/cassandra/db/migration/AddKeyspace.java
* /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java
* 
/cassandra/trunk/test/unit/org/apache/cassandra/thrift/ThriftValidationTest.java
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/src/java/org/apache/cassandra/db/DefsTable.java
* /cassandra/trunk/src/java/org/apache/cassandra/cql/AlterTableStatement.java
* /cassandra/trunk/src/java/org/apache/cassandra/config/KSMetaData.java
* 
/cassandra/trunk/src/java/org/apache/cassandra/db/migration/UpdateKeyspace.java
* 
/cassandra/trunk/src/java/org/apache/cassandra/db/migration/AddColumnFamily.java
* /cassandra/trunk/test/unit/org/apache/cassandra/config/CFMetaDataTest.java
* /cassandra/trunk/test/unit/org/apache/cassandra/db/DefsTest.java
* /cassandra/trunk/src/java/org/apache/cassandra/config/CFMetaData.java
* /cassandra/trunk/test/unit/org/apache/cassandra/SchemaLoader.java


 clean up KSMetadata, CFMetadata
 ---

 Key: CASSANDRA-3032
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3032
 Project: Cassandra
  Issue Type: Task
  Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Trivial
 Fix For: 1.0

 Attachments: 3032.txt, 3032.txt


 There are too many conversion methods between Thrift and Avro and Native, 
 which is a potential source of bugs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

2011-08-24 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090417#comment-13090417
 ] 

Hudson commented on CASSANDRA-2761:
---

Integrated in Cassandra #1045 (See 
[https://builds.apache.org/job/Cassandra/1045/])
move drivers back in-tree until build issues can be fixed.  see 
CASSANDRA-2761

jbellis : 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1161216
Files : 
* 
/cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Column.java
* 
/cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java
* 
/cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/InvalidRequestException.java
* /cassandra/trunk/build.xml
* /cassandra/trunk/contrib
* /cassandra/trunk/drivers/java/README.txt
* 
/cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/SuperColumn.java
* /cassandra/trunk/drivers
* 
/cassandra/trunk/interface/thrift/gen-java/org/apache/cassandra/thrift/NotFoundException.java
* /cassandra/trunk
* /cassandra/trunk/drivers/java/build.properties.default
* /cassandra/trunk/drivers/java/build.xml


 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CASSANDRA-3074) comments and documentation for index_interval are misleading

2011-08-24 Thread Matthew F. Dennis (JIRA)

comments and documentation for index_interval are misleading


 Key: CASSANDRA-3074
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3074
 Project: Cassandra
  Issue Type: Bug
Reporter: Matthew F. Dennis
Assignee: Matthew F. Dennis
Priority: Minor


The comments and documentation for index_interval are misleading.  They state 
the larger the *sampling* the more effective the index as at the cost of space. 
 This is true, but in the context of the configuration variable it implies the 
larger the *setting* is the larger the index is while in fact it's the opposite 
of that.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

svn commit: r1161239 - in /cassandra/trunk: CHANGES.txt NEWS.txt

Author: jbellis
Date: Wed Aug 24 19:30:16 2011
New Revision: 1161239

URL: http://svn.apache.org/viewvc?rev=1161239view=rev
Log:
update CHANGES, NEWS

Modified:
cassandra/trunk/CHANGES.txt
cassandra/trunk/NEWS.txt

Modified: cassandra/trunk/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/CHANGES.txt?rev=1161239r1=1161238r2=1161239view=diff
==
--- cassandra/trunk/CHANGES.txt (original)
+++ cassandra/trunk/CHANGES.txt Wed Aug 24 19:30:16 2011
@@ -13,11 +13,12 @@
  * reset CF and SC deletion times after gc_grace (CASSANDRA-2317)
  * optimize away seek when compacting wide rows (CASSANDRA-2879)
  * single-pass streaming (CASSANDRA-2677)
- * use reference counting for deleting sstables instead of relying on the GC
+ * use reference counting for deleting sstables instead of relying on GC
(CASSANDRA-2521)
- * store hints as serialized mutations instead of pointers to data rows
- * store hints in the coordinator node instead of in the closest 
-   replica (CASSANDRA-2914). 
+ * store hints as serialized mutations instead of pointers to data row
+   (CASSANDRA-2045)
+ * store hints in the coordinator node instead of in the closest replica 
+   (CASSANDRA-2914)
  * add row_cache_keys_to_save CF option (CASSANDRA-1966)
  * check column family validity in nodetool repair (CASSANDRA-2933)
  * use lazy initialization instead of class initialization in NodeId
@@ -42,6 +43,7 @@
  * clean up KSMetadata, CFMetadata from unnecessary
Thrift-Avro conversion methods (CASSANDRA-3032)
 
+
 0.8.5
  * fix NPE when encryption_options is unspecified (CASSANDRA-3007)
  * include column name in validation failure exceptions (CASSANDRA-2849)

Modified: cassandra/trunk/NEWS.txt
URL: 
http://svn.apache.org/viewvc/cassandra/trunk/NEWS.txt?rev=1161239r1=1161238r2=1161239view=diff
==
--- cassandra/trunk/NEWS.txt (original)
+++ cassandra/trunk/NEWS.txt Wed Aug 24 19:30:16 2011
@@ -9,6 +9,18 @@ Upgrading
 Features
 
 - cassandra.bat install will install Cassandra as a Windows Service
+- SSTable compression can be enabled by setting options ???
+- Compressed SSTable blocks are checksummed to protect against bitrot
+- New LevelDB-inspired compaction algorithm can be enabled by setting
+  option ???
+- Windows Service (cassandra.bat install to enable)
+
+Other
+-
+- Hinted Handoff is substantially more robust, with the result that
+  when HH is enabled, repair only needs to be run if a node crashes.
+- Because of this, read repair is disabled now by default on newly
+  created ColumnFamilies.
 
 
 0.8.4

[jira] [Updated] (CASSANDRA-3074) comments and documentation for index_interval are misleading

2011-08-24 Thread Matthew F. Dennis (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew F. Dennis updated CASSANDRA-3074:
-

Attachment: 3074-cassandra-0.8.patch

 comments and documentation for index_interval are misleading
 

 Key: CASSANDRA-3074
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3074
 Project: Cassandra
  Issue Type: Bug
Affects Versions: 0.8.4
Reporter: Matthew F. Dennis
Assignee: Matthew F. Dennis
Priority: Minor
 Attachments: 3074-cassandra-0.8.patch


 The comments and documentation for index_interval are misleading.  They state 
 the larger the *sampling* the more effective the index as at the cost of 
 space.  This is true, but in the context of the configuration variable it 
 implies the larger the *setting* is the larger the index is while in fact 
 it's the opposite of that.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2478) Custom CQL protocol/transport


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-2478:
--

 Labels: cql  (was: )
Summary: Custom CQL protocol/transport  (was: Custom protocol/transport)

 Custom CQL protocol/transport
 -

 Key: CASSANDRA-2478
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Priority: Minor
  Labels: cql

 A custom wire protocol would give us the flexibility to optimize for our 
 specific use-cases, and eliminate a troublesome dependency (I'm referring to 
 Thrift, but none of the others would be significantly better).  Additionally, 
 RPC is bad fit here, and we'd do better to move in the direction of something 
 that natively supports streaming.
 I don't think this is as daunting as it might seem initially.  Utilizing an 
 existing server framework like Netty, combined with some copy-and-paste of 
 bits from other FLOSS projects would probably get us 80% of the way there.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3073) liveSize() calculation is wrong in case of overwrite

2011-08-24 Thread Yang Yang (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090440#comment-13090440
 ] 

Yang Yang commented on CASSANDRA-3073:
--

Jonathan:

I looked at the SlabAllocator code, I think it does create a problem for 
update-oriented workload: as you said, its live size is essentially the 
throughput. thus even if you have a single counter, your memory consumption 
quickly grows, and you have to flush out many tiny SSTables. could we add a 
config option to control to choose the SlabAllocator or the native one? in the 
counter case, it seems the disadvantages of many tiny SSTables is worse than 
possible fragmentation.

also could you please educate me more on how the current SlabAllocator code 
works? (it's quite different from standard slab allocation as described in 
books since it does not have the free() )   I thought by the time minor GC 
happens, some old columns in the Region has been superceded and are useless, so 
the Region already has internal fragmentation, and then this Region is promoted 
to old gen, so old gen would still have internal fragmentation (actually a lot 
in case of counters). or am I missing something?

Thanks
Yang

 liveSize() calculation is wrong in case of overwrite
 

 Key: CASSANDRA-3073
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3073
 Project: Cassandra
  Issue Type: Bug
Reporter: Yang Yang
Priority: Minor
 Attachments: 
 0001-liveSize-is-different-from-throughput-particularly-w.patch


 currently liveSize() is the sum of currentThroughput.
 this definition is wrong if most of the operations are overwrite, or counter 
 (which is essentially overwrite).
 for example, the following code should always keep a single entry in db, with 
 one row, one cf, one column, and supposedly should have a size of only about 
 100 bytes.
 connect localhost/9160;  
 create keyspace blah;
 use blah;
 create column family cf2 with memtable_throughput=1024 and 
 memtable_operations=1  ;
 set the cassandra.yaml 
 memtable_total_space_in_mb: 20
 to make the error appear faster (but if u set to default, still same issue 
 will appear)
 then we use a simple pycassa  script:
  pool = pycassa.connect('blah')
  mycf = pycassa.ColumnFamily(pool,cf2);
  for x in range(1,1000) :
 ... xx = mycf.insert('key1',{'col1':{}.format(x)})
 ... 
 you will see sstables being generated with only sizes of a few k, though we 
 set the CF options to get high SSTable sizes

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

2011-08-24 Thread Rick Shaw (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090441#comment-13090441
 ] 

Rick Shaw commented on CASSANDRA-2761:
--

I don't see any driver code in the move? The {{/driver}} sub-directory now 
exists but there is nothing underneath?

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090445#comment-13090445
 ] 

Jonathan Ellis commented on CASSANDRA-2761:
---

https://svn.apache.org/repos/asf/cassandra/trunk/drivers/

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CASSANDRA-2489) better not close the out/error stream from CassandraDaemon


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-2489:
--

Fix Version/s: 1.1
 Assignee: (was: paul cannon)
   Labels: lhf  (was: )

 better not close the out/error stream from CassandraDaemon
 --

 Key: CASSANDRA-2489
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2489
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jackson Chung
Priority: Minor
  Labels: lhf
 Fix For: 1.1


 When cassandra is started in the background (-p /tmp/pidfile.pid), the 
 System.out System.err is closed. That may not be suitable in case where 
 capturing thread dump via traditional sigquit is preferred (kill -3 pid ). 
 This could be useful especially when jmx collection is failing, or ability to 
 do some little script to continuously capture thread dump via a script in the 
 background.
 closing System.err could also potentially be swallowing fatal error that 
 crashing the jvm. 
 I would suggest make change to the stocked cassandra start script, when the 
 intends is not running in foreground, (ie running in background) then 
 redirect the standard output/error to a file, eg: 
 /var/log/cassandra/cassandra.out 21 
 currently i apply a workaround to the script by faking the 
 cassandra-foreground flag as -Dcassandra-foreground=no since the check is 
 simply look for null:
 {code:title=AbstracCassandraDaemon.activate()}
if (System.getProperty(cassandra-foreground) == null)
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090464#comment-13090464
]

Eric Evans commented on CASSANDRA-2761:
---

{quote}
It's been another two weeks and we're still in this no-man's land where git
can't see drivers
{quote}

So does this mean you've decided Git is hard a requirement? Our project is
(unfortunately )managed in SVN. You know if it were up to me we'd be using Git
for source control, but it's not up to me and we don't.

{quote}
...anything that depends on jdbc like 3010 is basically SOL.
{quote}

As I've already mentioned, CASSANDAR-3010 is for a JDBC using _application_.
If it's SOL unless the driver is embedded in the tree, then so is every other
application that would make use of the driver. If the driver is so bad, maybe
no one should be using it. Why are we giving ourselves special treatment?

{quote}
Again, I'm not against purity...
{quote}

By saying purity it sounds like you're dismissing it as something that's
based on aesthetics. I assure that's not the case, it's about avoiding the
inevitable lock-step relationship release-wise.

{quote}
...but it's clear that the original breaking out of drivers/ was done
prematurely (was there even a Jira ticket with a patch?
{quote}

There was a Jira yes, though I'm pretty sure it done as part of larger set of
tasks, something with a description other than relocate drivers out of tree.
And, I don't think it was in a patch, no, due to the fact that a large move
with some minor changes was (a) straightforward, and (b) would have needed
rebasing several times a day.

{quote}
It looks like we went from that's a good idea on -dev to ripping apart svn).
I've reverted things until the breakout can be done properly.
{quote}

So all I need to do is find a ticket and a +1 and I can -1 this, and revert
your revert?

JDBC driver does not build
--

Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt

Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring

2011-08-24 Thread Eric Falcao (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090472#comment-13090472
 ] 

Eric Falcao commented on CASSANDRA-3023:


Just another quick note: by the comments here, I thought I'd be able to do a 
rolling restart to 0.8.4

By the time I got to my last node and stopped it, my clients were under the 
impression that the whole cluster was down (it wasn't) but checking cassandra 
logs I saw the stacktrace above spewing out 5-10 times per second. When the 
last node was started, the stacktraces were still flowing rapidly. I downgraded 
my entire cluster to 0.8.3 to stop the error and bring my site back online

Any insight?

 NPE in describe_ring
 

 Key: CASSANDRA-3023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.4
Reporter: Eric Falcao
Assignee: Brandon Williams
 Fix For: 0.8.5

 Attachments: 3023.txt


 Not sure how much of the following is relevant besides the stack trace, but 
 here I go:
 I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't 
 restarted. I upgraded to 0.8.4 in the following fashion:
 -edited seeds
 -stopped both DC1 nodes
 -upgraded jars
 -started both nodes at the same time
 The non-seed node came up first and showed the following error. Then when the 
 seed node came up, the error went away on the non-seed node but started 
 occurring on the seed node:
 ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) 
 Internal error processing describe_ring
 java.lang.NullPointerException
   at 
 org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623)
   at 
 org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664)
   at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

2011-08-24 Thread T Jake Luciani (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090481#comment-13090481
 ] 

T Jake Luciani commented on CASSANDRA-2761:
---

bq.  Our project is (unfortunately )managed in SVN

putting a sub-project in a svn root isn't the way to do it for SVN.

Another issue is the drivers build depends on cassandra.  That makes this even 
more strange. Can't drivers live in /trunk and still have it's own releases?



 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3023) NPE in describe_ring

2011-08-24 Thread Eric Falcao (JIRA)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090489#comment-13090489
 ] 

Eric Falcao commented on CASSANDRA-3023:


I think my clients may have rapidly been calling 
describe_ring.hrm..which should have stopped NPE'ing after the full 
(but rolling) upgrade.

 NPE in describe_ring
 

 Key: CASSANDRA-3023
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3023
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 0.8.4
Reporter: Eric Falcao
Assignee: Brandon Williams
 Fix For: 0.8.5

 Attachments: 3023.txt


 Not sure how much of the following is relevant besides the stack trace, but 
 here I go:
 I have a 2 DC, 2 node per DC cluster. DC1 had it's seed replaced but I hadn't 
 restarted. I upgraded to 0.8.4 in the following fashion:
 -edited seeds
 -stopped both DC1 nodes
 -upgraded jars
 -started both nodes at the same time
 The non-seed node came up first and showed the following error. Then when the 
 seed node came up, the error went away on the non-seed node but started 
 occurring on the seed node:
 ERROR [pool-2-thread-15] 2011-08-12 22:32:27,438 Cassandra.java (line 3668) 
 Internal error processing describe_ring
 java.lang.NullPointerException
   at 
 org.apache.cassandra.service.StorageService.getRangeToRpcaddressMap(StorageService.java:623)
   at 
 org.apache.cassandra.thrift.CassandraServer.describe_ring(CassandraServer.java:731)
   at 
 org.apache.cassandra.thrift.Cassandra$Processor$describe_ring.process(Cassandra.java:3664)
   at org.apache.cassandra.thrift.Brisk$Processor.process(Brisk.java:464)
   at 
 org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090494#comment-13090494
]

Jonathan Ellis commented on CASSANDRA-2761:
---

bq. There was a Jira yes

I couldn't find one, and the svn commit messages didn't mention it. I still
can't find one.

bq. So all I need to do is find a ticket and a +1 and I can -1 this, and revert
your revert?

The point of making a ticket with a patch (or a shell script if you're throwing
svn refactoring around -- you can do mv's from a working copy, not just on the
repository, btw) is that people can review it and see if the result matches
what they thought they were going to get out of it. In this case it's clear
that it didn't, and we ended up with making things worse in exchange for a
promise to clean it up eventually.

(Of course, even with proper review, sometimes we've needed to revert things
after unexpected problems arose. But skipping the review makes that more
likely.)

It's been *over two months.* So let's reboot, and do it right. Note that this
time around I got everything in one commit (well, one for trunk, and one for
drivers) so reverting the revert will be easy.

JDBC driver does not build
--

Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt

Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090497#comment-13090497
 ] 

Eric Evans commented on CASSANDRA-2761:
---

bq. putting a sub-project in a svn root isn't the way to do it for SVN.

What is?

bq. Another issue is the drivers build depends on cassandra. That makes this 
even more strange. Can't drivers live in /trunk and still have it's own 
releases?

We had it that way originally.  It made releasing a pain, and left people with 
the expectation that the driver version to use was the one that corresponded to 
source it was with (which is unavoidable).

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090498#comment-13090498
 ] 

Jonathan Ellis commented on CASSANDRA-2761:
---

bq. Can't drivers live in /trunk and still have it's own releases?

Right, that seems like the best interim solution to me.  (I thought we could 
even delete it from old branches to make it clear that it's not in lockstep 
with the rest of the tree, but Eric pointed out that if something like 3010 is 
depending on it, we can't do that.  Still, having it present but frozen in 
the branches feels like a relatively minor downside.)

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090501#comment-13090501
 ] 

Eric Evans commented on CASSANDRA-2761:
---

How do we reboot and do it right?  Your requirements as I understand them are 
structured in such a way that keeping them in-tree is the only solution.  

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090502#comment-13090502
 ] 

Jonathan Ellis commented on CASSANDRA-2761:
---

bq. left people with the expectation that the driver version to use was the one 
that corresponded to source it was with

I suspect this was when svn was effectively the only way to get a driver.  My 
experience is that even most people building from source use a tarball, not 
svn.  So the combination of making drivers available on maven, PyPI, etc., with 
their own version numbers, should address this.

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090505#comment-13090505
 ] 

Eric Evans commented on CASSANDRA-2761:
---

bq. Right, that seems like the best interim solution to me. (I thought we could 
even delete it from old branches to make it clear that it's not in lockstep 
with the rest of the tree, but Eric pointed out that if something like 3010 is 
depending on it, we can't do that. Still, having it present but frozen in the 
branches feels like a relatively minor downside.)

Except that people's expectation will always be that the version they need is 
the one that came with their software (which will likely be something 
pre-release).  It is completely unrealistic to expect folks to just Know Better 
here. 

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090521#comment-13090521
 ] 

Jonathan Ellis commented on CASSANDRA-2761:
---

bq. people's expectation will always be that the version they need is the one 
that came with their software

I don't understand.  What version will come with their [server]?

Consider postgresql: the server is distributed on postgresql.org, and psycopg 
is distributed over PyPI.  Nobody gets confused about staying on an obsolete 
version of psycopg.

That's the model I see us moving towards.  (As you know, we recently got the 
Python cql driver on PyPI.)

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[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=13090530#comment-13090530
 ] 

Mikko Koppanen commented on CASSANDRA-3025:
---

Hi,

I don't think there really table level metadata but I think attributes 
(http://uk3.php.net/manual/en/pdostatement.getattribute.php) could be used for 
this. Will investigate furhter.

For the StandardLongA thing, I copied the queries from here: 
http://svn.apache.org/viewvc/cassandra/trunk/test/system/test_cql.py?revision=1159474view=markup
 around line 54. Changed now in the later versions:

https://github.com/mkoppanen/php-pdo_cassandra/blob/master/tests/018-int.phpt

Also, numeric types should be properly coming as PHP integers now. I need to 
add a bit of caching on the describe_keyspace(s).

What is the recommended way to return UUID values? I did a quick test and it 
seems that they are coming back as binary, should I convert them to the ASCII 
version (uuid_unparse)?




 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] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090535#comment-13090535
 ] 

Jonathan Ellis commented on CASSANDRA-2761:
---

One final thought: by coincidence, we broke the JDBC build again today with 
CASSANDRA-3039.  This isn't the first time this has happened.  It's a minor win 
but not negligible to catch those before commit because ant test runs both 
suites.

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090544#comment-13090544
]

Eric Evans commented on CASSANDRA-2761:
---

{quote}
I don't understand. What version will come with their [server]?
{quote}

Wherever we publish the source, be it an SVN checkout with an SVN revision ID,
a date-based development snapshot, or a full-on release artifact, if there is
driver source contained within then people are going to be encouraged to think
of those drivers as being the same version as the node (e.g. 0.8.9). They're
also going to be encouraged to think that those drivers are the best choice to
use with the corresponding node. It's futile to think they won't, and having
other vectors (www.a.o, PyPI, etc), will only add to the confusion.

{quote}
Consider postgresql: the server is distributed on postgresql.org, and psycopg
is distributed over PyPI. Nobody gets confused about staying on an obsolete
version of psycopg.

That's the model I see us moving towards. (As you know, we recently got the
Python cql driver on PyPI.)
{quote}

You make an excellent point. Pyscopg is maintained in a completely different
repository (git://luna.dndg.it/public/psycopg2.git) than Postgesql
(git://git.postgresql.org/git/postgresql.git) and is released (and published)
separately, (which is in fact consistent with best practice elsewhere).

JDBC driver does not build
--

Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt

Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090552#comment-13090552
]

Eric Evans commented on CASSANDRA-2761:
---

bq. One final thought: by coincidence, we broke the JDBC build again today with
CASSANDRA-3039. This isn't the first time this has happened. It's a minor win
but not negligible to catch those before commit because ant test runs both
suites.

Broke why? Because of Cassandra code that the driver depends on? That would
be an argument in favor of stabalizing the dependent code.

And, the inverse of this is that the drivers should ultimately be getting
tested against trunk, each active branch, and all past released versions
(limited of course to CQL availability). That is only going to be practical
through CI, and is made harder by your monolithic approach.

JDBC driver does not build
--

Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt

Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build

[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090557#comment-13090557
]

Jonathan Ellis commented on CASSANDRA-2761:
---

bq. if there is driver source contained

Almost all non-developers get the source from a release tarball, not svn. Do
we publish drivers/ in the source tarballs? If so that's easy enough to fix.

Anyone actually using svn I'm willing to educate. You can give them my email.
:)

bq. Pyscopg is maintained in a completely different repository

But as far as users are concerned that is irrelevant.

If you want examples of drivers in the same tree that are also not causing
confusion, I can point you to https://github.com/mongodb/mongo and
https://github.com/mongodb/mongo/tree/master/client. Also
http://hg.basho.com/riak/src/5ffa6ae7e699
(http://hg.basho.com/riak/src/5ffa6ae7e699/client_lib/) and
https://github.com/voldemort/voldemort
(https://github.com/voldemort/voldemort/tree/master/clients).

JDBC driver does not build
--

Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt

Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-957) convenience workflow for replacing dead node

2011-08-24 Thread Nick Bailey (JIRA)

[
https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090577#comment-13090577
]

Nick Bailey commented on CASSANDRA-957:
---

So a few questions:

* In Gossiper.doStatusCheck() you made it ignore any state that is for the
local endpoint and is not a dead state. Shouldn't it just always ignore any
state about the local endpoint though? Basically what it was doing previously?
* Basically the same question about Gossiper.applyStateLocally() the loop
continues if the state is for the local node and the state is dead. Why would
we want to apply a live local state?
* Does the hibernate state need the true/false value? Seems like all we care
about is that it is set at all. Looks like we we are starting up right now we
automatically go into a hibernate state, then we go into a bootstrap state
afterwards if the specified a replace token. Seems like we shouldn't set a
state at all until we know we are doing one of replace/bootstrap/just joining.
* It looks like right now you could specify a replace token that isn't part of
the cluster. If that happens we should throw an exception and tell the user to
do the normal bootstrap process.
* Why use the last gossip time to determine if the node we are replacing is
alive? Why not just check gossip to see if the ring thinks it is alive?
* We should update the the message for the exception that is thrown when you
try to bootstrap to an existing token. It should indicate either remove the
dead node or follow this replacement process.
* I'm not sure why we are calling updateNormalToken() in the
StorageService.bootstrap() method when it's a token replacement.
* A little bit of doc on this would be good, maybe in cassandra.yaml? Just on
how to pass the argument to the startup process.

I also need to dive into the hint stuff a little bit more, I'm less familiar
with that code.

convenience workflow for replacing dead node

Key: CASSANDRA-957
URL: https://issues.apache.org/jira/browse/CASSANDRA-957
Project: Cassandra
Issue Type: Wish
Components: Core, Tools
Affects Versions: 0.8.2
Reporter: Jonathan Ellis
Assignee: Vijay
Fix For: 1.0

Attachments: 0001-Support-Token-Replace.patch,
0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch,
0001-Support-token-replace.patch, 0001-support-for-replace-token-v3.patch,
0002-Do-not-include-local-node-when-computing-workMap.patch,
0002-Rework-Hints-to-be-on-token.patch,
0002-Rework-Hints-to-be-on-token.patch,
0002-upport-for-hints-on-token-v3.patch,
0003-Make-HintedHandoff-More-reliable.patch,
0003-Make-hints-More-reliable.patch, 0003-making-bootstrap-sleep-longer.patch

Original Estimate: 24h
Remaining Estimate: 24h

Replacing a dead node with a new one is a common operation, but nodetool
removetoken followed by bootstrap is inefficient (re-replicating data first
to the remaining nodes, then to the new one) and manually bootstrapping to a
token just less than the old one's, followed by nodetool removetoken is
slightly painful and prone to manual errors.
First question: how would you expose this in our tool ecosystem? It needs to
be a startup-time option to the new node, so it can't be nodetool, and
messing with the config xml definitely takes the convenience out. A
one-off -DreplaceToken=XXY argument?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090589#comment-13090589
 ] 

Eric Evans commented on CASSANDRA-2761:
---

So to summarize: You've decided.

I know that sounds a bit snarky, but you summarily reverted the change, in part 
based on reasoning that wasn't true (it doesn't build), and in part pending a 
reboot to meet unmeetable requirements.

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[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=13090600#comment-13090600
 ] 

Mikko Koppanen commented on CASSANDRA-3025:
---

Now that I think of it, would it make sense to add something similar to 
DESCRIBE KEYSPACE|TABLE ksname ?

 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] [Issue Comment Edited] (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=13090600#comment-13090600
 ] 

Mikko Koppanen edited comment on CASSANDRA-3025 at 8/24/11 11:00 PM:
-

Now that I think of it, would it make sense to add something similar to 
DESCRIBE COLUMNFAMILY|TABLE ksname ?

  was (Author: mkoppanen):
Now that I think of it, would it make sense to add something similar to 
DESCRIBE KEYSPACE|TABLE ksname ?
  
 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] [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=13090669#comment-13090669
 ] 

Mikko Koppanen commented on CASSANDRA-3025:
---

Test for UUIDs added: 
https://github.com/mkoppanen/php-pdo_cassandra/blob/master/tests/019-uuid.phpt

 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] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090719#comment-13090719
 ] 

Jonathan Ellis commented on CASSANDRA-2761:
---

If waiting for two months of we'll fix it real soon now is summarily, then 
yeah, I guess guilty as charged.

But it looks like you've restarted discussion on -dev, so I'll move there.

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[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=13090721#comment-13090721
 ] 

Jonathan Ellis commented on CASSANDRA-3025:
---

bq. What is the recommended way to return UUID values

Good question.  What does PHPCassa do?

bq. would it make sense to add something similar to DESCRIBE COLUMNFAMILY|TABLE

Yes: CASSANDRA-2477.  Until then we're making do with the old-style Thrift 
calls.



 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] [Commented] (CASSANDRA-2761) JDBC driver does not build


[ 
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090724#comment-13090724
 ] 

Eric Evans commented on CASSANDRA-2761:
---

Up until the July 21st, the scope of the ticket was building and running the 
unit tests (and as of July 21st that much was working).  It wasn't until Aug 
10th (and the creation of CASSANDRA-3010) that the discussion (and scope) 
changed.  Between the 10th and today there was no response to my last, then 4 
hours after Jake's comment the revert was made.

I already told you once today that I ascribed no malice in this, and I don't, 
but I think summarily is a fair assessment.

 JDBC driver does not build
 --

 Key: CASSANDRA-2761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
 Fix For: 1.0

 Attachments: jdbc-driver-build-v1.txt, 
 v1-0001-CASSANDRA-2761-cleanup-nits.txt


 Need a way to build (and run tests for) the Java driver.
 Also: still some vestigal references to drivers/ in trunk build.xml.
 Should we remove drivers/ from the 0.8 branch as well?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3025) PHP/PDO driver for Cassandra CQL