from:"Eric Evans \(Commented\) \(JIRA\)"

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

2012-04-06 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3990:
---

bq. we'll see what Eric thinks.

Looks good to me.  I've merged this to cassandra-1.1 and trunk, I'll leave it 
to Sylvain's judgement as to whether or not this should be merged to 
cassandra-1.1.0 as well.

Thanks.

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v3-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v3-0002-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications

2012-04-02 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3665:
---

For what it's worth, and whether or not it's Right, this was more or less 
intentional.  The only dependencies added were those needed by the classes in 
{{o.a.c.cql.jdbc}}. {{UUIDGen}} is an example of something that was added as a 
dependency (not to be used directly), and the only transient dependencies 
included were those needed by the methods the Jdbc* classes access.

TL;DR, that jar hasn't been setup to use {{UUIDGen.getTimeUUIDBytes()}}.

I realize that's probably not at all obvious though, so we should probably come 
up with a better solution (and open a separate ticket).

Unfortunately, simply including {{FBUtilities}} is non-trivial because that 
results in mountains of transient dependencies being pulled in.  I think we'll 
either need to refactor our way around {{FBUtilities}}, or split up {{UUIDGen}}.

 [patch] allow for clientutil.jar to be used without the base cassandra.jar 
 for client applications
 --

 Key: CASSANDRA-3665
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3665
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 1.0.8
Reporter: Dave Brosius
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.0.10

 Attachments: fail_client_utils_test.diff, fix_client_util_jar.diff, 
 v1-0001-CASSANDRA-3665-test-to-expose-missing-dependencies.txt, 
 v1-0002-eliminate-dependency-on-FBUtilities.txt


 clientutil.jar can't be run from a client by itself without the presence of 
 cassandra.jar which seems wrong. Added needed classes to run by itself.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

2012-03-30 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3990:
---

bq. Cool. Do you think it's worth having an extra shortcut-y parameter like -3 
or --cql3 instead of --cqlversion=3.0.0?

Yeah, that probably would be better.  I'll update the patch accordingly.

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3

2012-03-30 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3990:
---

bq.  I'll update the patch accordingly.

Attached as v2

 cqlsh support for CQL 3
 ---

 Key: CASSANDRA-3990
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Eric Evans
Priority: Minor
 Fix For: 1.1.0

 Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, 
 v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt


 Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to 
 choose the cql version at launch time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3991) Investigate importance of jsvc in debian packages

2012-03-16 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3991:
---

bq. Certainly OOMing in a loop, with heap dumps enabled, is not a thing we 
really ought to be doing.

FWIW, jsvc isn't restarting for an OOM, it requires the JVM itself to crash 
(something I don't think happens very frequently these days).

 Investigate importance of jsvc in debian packages
 -

 Key: CASSANDRA-3991
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3991
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
Priority: Minor
 Fix For: 1.1.1


 jsvc seems to be buggy at best.  For instance, if you set a small heap like 
 128M it seems to completely ignore this and use as much memory as it wants.  
 I don't know what this is buying us over launching /usr/bin/cassandra 
 directly like the redhat scripts do, but I've seen multiple complaints about 
 its memory usage.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3991) Investigate importance of jsvc in debian packages

2012-03-06 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3991:
---

Java's platform neutrality makes it impossible to properly daemonize, jsvc is
meant as a work-around. It disassociates from the controlling terminal,
becomes the session leader, double-forks, sets the PWD to /, sets the umask
to 0, closes file descriptors, etc, etc.

As Sylvain mentions, it's also supposed to restart when the JVM (not the app)
crashes.

bq. I guess the main point of JSVC is this? Jsvc allows the application (e.g.
Tomcat) to perform some privileged operations as root (e.g. bind to a port
1024), and then switch identity to a non-privileged user. We don't even use
that...

We might be opening root-owned files at start-up (we used to anyway).

If jsvc is buggy (is this memory thing the only problem?) the options would
seem to be:

# File a bug report with Debian, commons-daemon, or both
# Fix the jsvc bug(s)
# Try to properly daemonize entirely from shell (I tried doing this with
{{bin/cassandra}} FWIW, I don't think it's practical)
# Rip out jsvc and call it Good Enough(tm)

Looking at the source, jsvc seems pretty simple. I might be willing to take a
crack at bug-fixing in the weeks to come assuming a) I knew how to reproduce
the issue(s), and b) everyone doesn't already have their hearts set on #4.

Investigate importance of jsvc in debian packages
-

Key: CASSANDRA-3991
URL: https://issues.apache.org/jira/browse/CASSANDRA-3991
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Brandon Williams
Assignee: Brandon Williams
Fix For: 1.1.1

jsvc seems to be buggy at best. For instance, if you set a small heap like
128M it seems to completely ignore this and use as much memory as it wants.
I don't know what this is buying us over launching /usr/bin/cassandra
directly like the redhat scripts do, but I've seen multiple complaints about
its memory usage.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3671) provide JMX counters for unavailables/timeouts for reads and writes

2012-03-05 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3671:
---

Also, is there any reason this couldn't be applied to the 1.1 branch?

 provide JMX counters for unavailables/timeouts for reads and writes
 ---

 Key: CASSANDRA-3671
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3671
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Peter Schuller
Assignee: Peter Schuller
Priority: Minor
 Fix For: 1.2

 Attachments: CASSANDRA-3671-trunk-coda-metrics-203-withjar.txt, 
 CASSANDRA-3671-trunk-coda-metrics-v1.txt, 
 CASSANDRA-3671-trunk-coda-metrics-v2.txt, CASSANDRA-3671-trunk-v2.txt, 
 CASSANDRA-3671-trunk.txt, v1-0001-CASSANDRA-3671-trunk-coda-metrics-v2.txt.txt


 Attaching patch against trunk.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3671) provide JMX counters for unavailables/timeouts for reads and writes

2012-03-02 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3671:
---

I had some problems with the most recent patch 
(CASSANDRA-3671-trunk-coda-metrics-203-withjar.txt), it seems to be missing the 
jar and {{src/java/org/apache/cassandra/metrics/ClientRequestMetrics.java}}.

v1-0001-CASSANDRA-3671-trunk-coda-metrics-v2.txt.txt is 
CASSANDRA-3671-trunk-coda-metrics-v2.txt with the jar file added.

Otherwise, +1 from me.

 provide JMX counters for unavailables/timeouts for reads and writes
 ---

 Key: CASSANDRA-3671
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3671
 Project: Cassandra
  Issue Type: Improvement
  Components: Tools
Reporter: Peter Schuller
Assignee: Peter Schuller
Priority: Minor
 Fix For: 1.2

 Attachments: CASSANDRA-3671-trunk-coda-metrics-203-withjar.txt, 
 CASSANDRA-3671-trunk-coda-metrics-v1.txt, 
 CASSANDRA-3671-trunk-coda-metrics-v2.txt, CASSANDRA-3671-trunk-v2.txt, 
 CASSANDRA-3671-trunk.txt, v1-0001-CASSANDRA-3671-trunk-coda-metrics-v2.txt.txt


 Attaching patch against trunk.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3791) Support query by names for compact CF

2012-02-06 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3791:
---

bq. It's not really important but for info, the test seems to fail here with...

Oh, for future reference, you need Python = 2.7

bq. However, I look at the queries and result on that test and I didn't see 
anything wrong on what's returned. However, the test is asserting wrong things. 
When inserting data in the 'Clicks' CF, for the second userid 
(d9c9dced-d539-4bce-9ccb-dc59a9e9136f), you update the same column multiple 
times. The inserts look like

Gah, you're right of course.  Sorry for being stupid.

LGTM; +1

 Support query by names for compact CF
 -

 Key: CASSANDRA-3791
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3791
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
  Labels: cql3
 Fix For: 1.1

 Attachments: 0001-Refactor-select.patch, 
 0002-Allow-IN-on-last-column-of-PRIMARY-KEY.patch


 Current code don't allow doing a query by names on wide rows (compact CF). 
 I.e. with:
 {noformat}
 CREATE TABLE test1 (
 k int,
 c int,
 v int,
 PRIMARY KEY (k, c)
 ) WITH COMPACT STORAGE;
 {noformat}
 you cannot do:
 {noformat}
 SELECT v FROM test1 WHERE k = 0 AND c IN (5, 2, 8)
 {noformat}
 even though this is a simple name query.
 This ticket proposes to allow it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3791) Support query by names for compact CF

2012-02-03 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3791:
---

bq. Not sure I understand what you mean, it's supposed to return all matching 
results (if the code doesn't do that, it's a bug). Taking the example in the 
description, it should return 3 results, one for each value of 'c'.

Yeah, it's definitely not working that way here.

There is a scqeal test for this (https://github.com/acunu/scqeal).  From the 
top-level directory run:

{noformat}
CQL_VERSION=3.0.0 DEBUG=1 SET_CQL_VERSION=3.0.0 
CASSANDRA_HOME=/path/to/cassandra \
./runtests -sv 
scqeal.tests.test_select:TestSelect.compactcf_query_by_names_test
{noformat}

 Support query by names for compact CF
 -

 Key: CASSANDRA-3791
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3791
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
  Labels: cql3
 Fix For: 1.1

 Attachments: 0001-Refactor-select.patch, 
 0002-Allow-IN-on-last-column-of-PRIMARY-KEY.patch


 Current code don't allow doing a query by names on wide rows (compact CF). 
 I.e. with:
 {noformat}
 CREATE TABLE test1 (
 k int,
 c int,
 v int,
 PRIMARY KEY (k, c)
 ) WITH COMPACT STORAGE;
 {noformat}
 you cannot do:
 {noformat}
 SELECT v FROM test1 WHERE k = 0 AND c IN (5, 2, 8)
 {noformat}
 even though this is a simple name query.
 This ticket proposes to allow it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3791) Support query by names for compact CF

2012-02-02 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3791:
---

Since this only returns one matching result (the last), it seems like it's 
bound to confuse a lot of people; Are we sure this is the best idea?

 Support query by names for compact CF
 -

 Key: CASSANDRA-3791
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3791
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
  Labels: cql3
 Fix For: 1.1

 Attachments: 0001-Refactor-select.patch, 
 0002-Allow-IN-on-last-column-of-PRIMARY-KEY.patch


 Current code don't allow doing a query by names on wide rows (compact CF). 
 I.e. with:
 {noformat}
 CREATE TABLE test1 (
 k int,
 c int,
 v int,
 PRIMARY KEY (k, c)
 ) WITH COMPACT STORAGE;
 {noformat}
 you cannot do:
 {noformat}
 SELECT v FROM test1 WHERE k = 0 AND c IN (5, 2, 8)
 {noformat}
 even though this is a simple name query.
 This ticket proposes to allow it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3822) JdbcDate.getString(ByteBuffer) appears to not be multithreaded safe

2012-02-01 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3822:
---

committed w/ minor changes (style and convention); thanks Dave!

 JdbcDate.getString(ByteBuffer) appears to not be multithreaded safe
 ---

 Key: CASSANDRA-3822
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3822
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Reporter: Dave Brosius
Assignee: Dave Brosius
Priority: Trivial
 Attachments: use_thread_local_sdfs.diff


 JdbcDate.getString(ByteBuffer) makes use of a static SimpleDateFormat
 static final SimpleDateFormat FORMATTER = new 
 SimpleDateFormat(DEFAULT_FORMAT);
 SimpleDateFormat is not thread safe, as it uses a field from parent class 
 DateFormat
 protected Calendar calendar;
 to convert dates to calendars.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3818) disabling m-a-t for fun and profit (and other ant stuff)

2012-01-30 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3818:
---

Changes attached as patches, and pushed to Github as: 
https://github.com/eevans/cassandra/tree/3818

0001 / 8ad3ad
0002 / 9e26a1
0003 / 294bd1

The first 3 changesets are basically cleanups.

0004 / fc8d65

Changeset #4 creates a new target called _test-all_, which runs test, 
test-compression, long-test, and test-clientutil.jar per the discussion on dev@

0005 / d110ae

Adds a property (-Dwithout.maven) that disables maven-base dependency 
resolution, (at least for the build and test targets).

0006 / e093d8

Adds a property (-Dwithout.rat) that disables the automatic prepending of 
license headers to the Thrift generated classes.

0007 / 1037a9

Adds a check that makes gen-thrift-java a noop if 
{{interface/cassandra.thrift}} has not been updated (useful in environments 
where the Thrift code is regenerated as part of the build).

 disabling m-a-t for fun and profit (and other ant stuff)
 

 Key: CASSANDRA-3818
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3818
 Project: Cassandra
  Issue Type: Bug
  Components: Core, Packaging
Affects Versions: 1.0.7
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: build
 Fix For: 1.0.8, 1.1

 Attachments: v1-0001-CASSANDRA-3818-keep-init-in-init-target.txt, 
 v1-0002-clean-up-avro-generation-dependencies-and-dependants.txt, 
 v1-0003-remove-useless-build-subprojects-target.txt, 
 v1-0004-group-test-targets-under-test-all.txt, 
 v1-0005-add-property-to-disable-maven-junk.txt, 
 v1-0006-add-property-to-disable-rat-license-header-writing.txt, 
 v1-0007-don-t-needlessly-regenerate-thrift-code.txt


 It should be possible to disable maven-ant-tasks for environments with more 
 rigid dependency control, or where network access isn't available.
 Patches to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3778) KEY IN (...) queries do not work

2012-01-27 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3778:
---

bq. I've created 
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=14
 but it wasn't reviewed yet by any of the driver committers (hint, hint ).

committed.

bq. You're right, this is a bug. As it happens, the refactor done in 
CASSANDRA-3791 fixes that bug (among other benefits), so let's maybe just deal 
with that patch.

OK, I'll add that to my list to have a look at (if no one beats me to it).

 KEY IN (...) queries do not work
 

 Key: CASSANDRA-3778
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3778
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Affects Versions: 1.1
Reporter: Eric Evans
Assignee: Sylvain Lebresne
  Labels: cql
 Fix For: 1.1


 {{...KEY IN (...)}} queries fail due to faulty validation.  A pull request 
 for cassandra-dtest was opened that demonstrates this: 
 https://github.com/riptano/cassandra-dtest/pull/2

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications

2012-01-26 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3665:
---

bq. UUIDGen.makeType1UUIDFromHost

Auh, there it is, a dependency on {{FBUtilities.hash()}}.

OK, since (sadly )smoke-testing seems to be the best way to go about this, the 
attached patches include a test that's meant to exercise the code in clientutil 
(including {{UUIDGen.makeType1UUIDFromHost}}), in order to spot the exceptions 
caused by unintentional dependencies.

And, instead of adding FBUtils to the jar (and the couple of dozen transitive 
dependencies), I added a hash function to {{UUIDGen}} (based on the one from 
FBUtils).

 [patch] allow for clientutil.jar to be used without the base cassandra.jar 
 for client applications
 --

 Key: CASSANDRA-3665
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3665
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 1.0.6
Reporter: Dave Brosius
Assignee: Dave Brosius
 Attachments: fix_client_util_jar.diff, 
 v1-0001-CASSANDRA-3665-test-to-expose-missing-dependencies.txt, 
 v1-0002-eliminate-dependency-on-FBUtilities.txt


 clientutil.jar can't be run from a client by itself without the presence of 
 cassandra.jar which seems wrong. Added needed classes to run by itself.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3778) KEY IN (...) queries do not work

2012-01-26 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3778:
---

bq. I just tried with code I just committed on trunk and the test above passes. 
Not sure when/what fixed it though. Are you still able to reproduce on the last 
code?

Nope, it passes now.  High five?

 KEY IN (...) queries do not work
 

 Key: CASSANDRA-3778
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3778
 Project: Cassandra
  Issue Type: Sub-task
  Components: API
Affects Versions: 1.1
Reporter: Eric Evans
  Labels: cql
 Fix For: 1.1


 {{...KEY IN (...)}} queries fail due to faulty validation.  A pull request 
 for cassandra-dtest was opened that demonstrates this: 
 https://github.com/riptano/cassandra-dtest/pull/2

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications

2012-01-25 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3665:
---

Where does this list of additional classes come from?  Was it tested, and if 
so, against which version?

I'm not sure if it's the best tool, but according to tattletale 
(http://www.jboss.org/tattletale), the classes we are missing are 
{{o.a.c.io.util.FileDataInput}}, {{o.a.c.io.util.FileUtils}}, and 
{{o.a.c.utils.FBUtilities}}.  That's not including transitive dependencies, 
(for which {{FBUtilities}} alone is a nightmare).

Even manually searching through the code I can't see where 
{{o.a.c.utils.ClosableIterator}} or {{o.a.c.config.ConfigurationException}} are 
needed.

TL;DR Let me know if I'm missing something, but it looks like this patch is 
adding classes which are not needed, and missing some which are.

{{FBUtilities}} is being pulled in by {{ByteBufferUtil}}, so I think the right 
answer there is to refactor, and move the relevant bits out, either into 
{{ByteBufferUtil}}, or into another class entirely.

 [patch] allow for clientutil.jar to be used without the base cassandra.jar 
 for client applications
 --

 Key: CASSANDRA-3665
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3665
 Project: Cassandra
  Issue Type: Improvement
Affects Versions: 1.0.6
Reporter: Dave Brosius
Assignee: Dave Brosius
 Attachments: fix_client_util_jar.diff


 clientutil.jar can't be run from a client by itself without the presence of 
 cassandra.jar which seems wrong. Added needed classes to run by itself.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3761) CQL 3.0

2012-01-24 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3761:
---

bq. +1 from me, assuming we get the python driver kinks worked out, and pending 
Eric's review

I'm still poking at it, but I was just about to suggest that we go ahead and 
commit it now.

Also, IMO, since this is an explicitly experimental feature, and because it 
could benefit from rapid iteration, I don't think we should subject it to the 
usual rules for a freeze.  In fact, we should also relax the ticket/review 
requirement, particular for simple issues that have no bearing on any of the 
discussed semantics.

 CQL 3.0
 ---

 Key: CASSANDRA-3761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3761
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 0001-CQL-3.0-v2.patch, 0001-CQL-3.0.patch, 
 0002-Add-support-for-switching-the-CQL-version-v2.patch, 
 0002-Add-support-for-switching-the-CQL-version.patch, 
 0003-Makes-batches-atomic-v2.patch, 0003-Makes-batches-atomic.patch, 
 0004-Thrift-gen-files-v2.patch, 0004-Thrift-gen-files.patch, cql_tests.py, 
 create_cf_syntaxes.txt


 This ticket is a reformulation/generalization of CASSANDRA-2474. The core 
 change of CQL 3.0 is to introduce the new syntaxes that were discussed in 
 CASSANDRA-2474 that allow to:
 # Provide a better/more native support for wide rows, using the idea of 
 transposed vie.
 # The generalization to composite columns.
 The attached text file create_cf_syntaxes.txt recall the new syntaxes 
 introduced.
 The changes proposed above allow (and strongly suggest in some cases) a 
 number of other changes to the language that this ticket proposes to 
 explore/implement (more details coming in the comments).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3761) CQL 3.0

2012-01-24 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3761:
---

bq. Agreed on both count. Let's still be careful not to break stuffs too much
though: it wouldn't look too nice if this was broken because of a stupid typo
or something in the final 1.1, even if that's just a 'developer preview'.

Of course.

bq. I'm good with committing directly obvious bug fix, but I think I'd prefer
we stick with tickets and review for anything bigger. If only because it
facilitates synchronization between us. But also because I think reviews help
keeping the code cleaner and more bug-free imho, even if that slows slightly
the process (and it allows better tracing of the changes).

Right, my thinking was that as of right now, it could benefit more from rapid
iteration than from exhaustive review. Obviously, that picture changes as
things become more solid and there is less low-hanging fruit.

Anyway, I think what I'm advocating for is common-sense, and it doesn't sound
like we disagree.

bq. What would be nice would be to make every ticket targeting cql 3 sub-task
of this ticket. Or at least that we tag them with cql3.

Agreed (to both).

CQL 3.0
---

Key: CASSANDRA-3761
URL: https://issues.apache.org/jira/browse/CASSANDRA-3761
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
Labels: cql
Fix For: 1.1

Attachments: 0001-CQL-3.0-v2.patch, 0001-CQL-3.0.patch,
0002-Add-support-for-switching-the-CQL-version-v2.patch,
0002-Add-support-for-switching-the-CQL-version.patch,
0003-Makes-batches-atomic-v2.patch, 0003-Makes-batches-atomic.patch,
0004-Thrift-gen-files-v2.patch, 0004-Thrift-gen-files.patch, cql_tests.py,
create_cf_syntaxes.txt

This ticket is a reformulation/generalization of CASSANDRA-2474. The core
change of CQL 3.0 is to introduce the new syntaxes that were discussed in
CASSANDRA-2474 that allow to:
# Provide a better/more native support for wide rows, using the idea of
transposed vie.
# The generalization to composite columns.
The attached text file create_cf_syntaxes.txt recall the new syntaxes
introduced.
The changes proposed above allow (and strongly suggest in some cases) a
number of other changes to the language that this ticket proposes to
explore/implement (more details coming in the comments).

[jira] [Commented] (CASSANDRA-3761) CQL 3.0

2012-01-23 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3761:
---

I'm still looking over this, but I thought I'd mention that I'm unable to get 
the tests to pass (most of them produce errors).   For example:

{noformat}
$ nosetests -sxv cql_tests.py 
cql_tests.TestCQL.counters_test ... ERROR

==
ERROR: cql_tests.TestCQL.counters_test
--
Traceback (most recent call last):
  File /usr/lib/pymodules/python2.7/nose/case.py, line 187, in runTest
self.test(*self.arg)
  File /home/eevans/dev/src/git/cassandra/cql_tests.py, line 339, in 
counters_test
cursor.execute(UPDATE clicks SET total = total + 1 WHERE userid = 1 AND 
url = 'http://foo.com')
  File /usr/local/lib/python2.7/dist-packages/cql/cursor.py, line 89, in 
execute
raise cql.ProgrammingError(Bad Request: %s % ire.why)
ProgrammingError: Bad Request: line 1:79 mismatched character 'EOF' expecting 
'''

--
Ran 1 test in 1.871s

FAILED (errors=1)
{noformat}

In this case, the error actually seems to make sense.  Since {{//}} is 
recognized as a comment.  Did the wrong version of the tests get attached maybe?

Another example is:

{noformat}
NameError: global name 'assert_invalid' is not defined
{noformat}

Where is {{assert_invalid}} meant to come from?

Also, I think the patches needs to be rebased in the wake of #3689 (although I 
think the conflicts are minor).

Thanks!

 CQL 3.0
 ---

 Key: CASSANDRA-3761
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3761
 Project: Cassandra
  Issue Type: New Feature
  Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 0001-CQL-3.0.patch, 
 0002-Add-support-for-switching-the-CQL-version.patch, 
 0003-Makes-batches-atomic.patch, 0004-Thrift-gen-files.patch, cql_tests.py, 
 create_cf_syntaxes.txt


 This ticket is a reformulation/generalization of CASSANDRA-2474. The core 
 change of CQL 3.0 is to introduce the new syntaxes that were discussed in 
 CASSANDRA-2474 that allow to:
 # Provide a better/more native support for wide rows, using the idea of 
 transposed vie.
 # The generalization to composite columns.
 The attached text file create_cf_syntaxes.txt recall the new syntaxes 
 introduced.
 The changes proposed above allow (and strongly suggest in some cases) a 
 number of other changes to the language that this ticket proposes to 
 explore/implement (more details coming in the comments).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3633) update stress to support prepared statements

2012-01-19 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3633:
---

bq. The most current changes can be found here: 
https://github.com/eevans/cassandra/tree/3633.stress

This branch added working support for prepared statements that used string 
arguments; In light of the conclusion to CASSANDRA-3634, more work will be 
needed

 update stress to support prepared statements
 

 Key: CASSANDRA-3633
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3633
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1


 The {{stress}} utility needs to be updated for testing prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

2012-01-17 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2474:
---

bq. I don't understand. You emailed the community for input, we created a wiki 
explaining the options. We've run out of paint for the bikeshed. Now that the 
work is being done we need to go back and re-explain the issue?

It was discussed, consensus reached, and then brand new, additional, and 
disruptive changes were tacked on, so _yes_.  Is that really so unreasonable?

 CQL support for compound columns and wide rows
 --

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 0001-Add-support-for-wide-and-composite-CFs.patch, 
 0002-thrift-generated-code.patch, 2474-transposed-1.PNG, 
 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 
 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, 
 screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

2012-01-17 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2474:
---

bq. But wishing for an alpha-release API to be 100% stable is a level of
fantasy that requires either much more optimism or a much larger ego to think
that you got it THAT right on your first try without ever building anything
substantial on it first, than I'm capable of generating. And we really are
talking alpha here; beta implies feature completness, or close to it.

Getting back to expectations, where was the expectation set that CQL was
alpha-release? I know I'm not the only one who missed that memo. Granted,
it's not feature-complete, but what is? Cassandra isn't feature-complete
either (or we wouldn't still be adding features).

bq. The users I've talked see clearly that although the ultimate goal does
include stability, an incomplete API is simply not ready to deliver on that.
Which is why you see the overwhelming majority of development still done on
classic clients like Hector and pycassa. (And which is why I'm pushing hard
to make CQL3/1.1 feature complete. I do want CQL to succeed, but I'm realistic
about where it stands today.)

Are you saying that after CQL3/1.1, that people can expect some level of
stability? I would of course love to see a Yes, but pretending that the need
to add or make changes won't continue, and the arguments about backward
compatibility being Hard won't continue to be relevant, require much more
optimism than I'm capable of generating.

And to be clear, when I talk about setting expectations for stability, I don't
mean No Changes, Ever. Like I said, I understand there is a balance to
strike. But, other than assuming breakage and being pleasantly surprised if
you dodge a bullet, what can our users expect today?

bq. Jake and Sylvain's proposal sounds like the only way we're going to be able
to deliver the remaining features we need while still maintaining a
compatibility escape hatch for applications built on early CQL version. But
let's be clear: past 1.1, anyone who wants the old cql package maintained is
going to need to roll up his sleeves and pitch in, because the rest of us have
plenty of things to spend our time on that are more valuable to the community
as a whole.

I think this an excellent idea, especially if we're very clear that CQL3 is
volatile. When the time comes that we're willing to commit to something, we
should be clear about that too. Bonus points if we can make a 2-3 transition
reasonable, or at least reasonably documented.

And, even if the number of CQL = 2.0 users is small enough to be considered
acceptable collateral damage, an orderly transition like this will go a long
way toward showing everyone that we're trying not to burn them.

CQL support for compound columns and wide rows
--

Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
Labels: cql
Fix For: 1.1

Attachments: 0001-Add-support-for-wide-and-composite-CFs.patch,
0002-thrift-generated-code.patch, 2474-transposed-1.PNG,
2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG,
2474-transposed-select.PNG, cql_tests.py, raw_composite.txt,
screenshot-1.jpg, screenshot-2.jpg

For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

2012-01-17 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2474:
---

bq. The 1.0 designation was Eric's. I didn't push back because...

Actually, the version I was going with at the time was 0.99.  My reasoning was 
that I felt that until the features that had been implemented got some real 
usage, it was naive to think that they were right.  I described it at the time 
as a way of communicating that it was meant to represent 1.0, but that the door 
was cracked open, just in case.

You (Jonathan) argued that it should be 1.0, because 0.99 would send the 
message that it wasn't ready, and would result in less adoption.

 CQL support for compound columns and wide rows
 --

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 0001-Add-support-for-wide-and-composite-CFs.patch, 
 0002-thrift-generated-code.patch, 2474-transposed-1.PNG, 
 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 
 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, 
 screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2012-01-17 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3634:
---

bq. Perhaps it is a JDBC specific problem but often, tooling will use setInt()
if it is a number to be stored in a string column and more frequently a
setString() for an integer field. The concern is the PreparedStatement suite of
methods provides a lot of flexibility to do these kinds of implied
transformations that will be difficult without cooperation between the client
and server. to do on the client side only, will require knowing the entire
potential schema cached on the client side.

I think I see what you're saying and this just falls under the strings are
easier argument. You're able to get away with more because it's the server
that's doing the marshaling for you. For example, it doesn't matter whether
the schema is Int32, Integer, Long, etc, as long as you pass something that
vaguely looks like a number, it'll do the Right Thing.

With binary arguments you will need to keep a client-side copy of the schema so
that you know how to encode each argument (like Thrift clients have been doing
for some time).

So if a user calls {{setString(10)}} where schema is LongType, you'll need to
first create a long from the string, and then marshal it to bytes for the
request.

Validation is also something that you're going to need to do client-side; I
don't think there is any validation that the server can do that it isn't
already. For example, with numeric types, other than validating the length of
the {{byte[]}} (think Long or Int32), there really aren't any bytes that would
be _invalid_.

compare string vs. binary prepared statement parameters
---

Key: CASSANDRA-3634
URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.1

Perform benchmarks to compare the performance of string and pre-serialized
binary parameters to prepared statements.

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2012-01-17 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

bq. Validation, transformation, or corrective action could be done on the 
server side if you knew how it was encoded in the first place; hence my 
suggestion.

That's pretty much what happens with string args though.  If you're going to be 
re-encoding byte arrays then it sort of defeats the purpose of pre-serializing 
to bytes in the first place, no?

 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2012-01-17 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

bq. Given that the primary purpose of a real PS api is for performance 
(otherwise we could just fake it client-side the way we used to with JDBC), and 
the feedback from client devs was mixed, I propose that we proceed with the 
binary PS api. Client implementers who do not wish to deal with this can 
continue to use the pure string based, non-PS API, and they are no worse off 
than before.

We don't exactly have consensus, but it's pretty obvious at this point that we 
probably never will.  And as Rick points out, we need to nail down something.

Does anyone want to take another look at the changes before committing?

https://github.com/eevans/cassandra/tree/3634.rebased

 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

2012-01-14 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2474:
---

bq. First, let's be clear about our priorities here. While backwards
compatibility is an important consideration, it is not a guarantee we have made
for CQL, nor should we at this stage in its development.

It's not about guarantees, it's about _expectations_.

Interface stability was _the_ motiviating factor behind CQL. Other arguments
became obvious later, yes, but that was what set the whole thing in motion. It
was born out of requirements that my employer at the time had, and it was the
reason they paid me to do the initial work.

Since then I've been very vocal about interface stability in every forum. It's
a message that has resonated extremely well, and something that seemed to have
consensus within the project; If I was speaking out of turn, no one stepped in
to tell me.

TL;DR The absence of an iron-clad guarantee doesn't mean that breakage isn't
unwanted, or won't come as a surprise. Breaking the language now (with plans
already laid to break it again in 1.2) exceeds my expectations, and I know it
exceeds others.

{quote}
As Eric points out, we have made breaking changes deliberately before, because
updating the language to add missing functionality made clear where we'd gotten
something wrong. Expecting anything else from a partially finished language is
totally unrealistic.

Keep in mind as well that maintaining deprecated features indefinitely is a
resource sink that we can ill afford. We have a relatively small set of active
developers, and time spent working around code supporting obsolete features,
perhaps fixing regressions caused by keeping it alive, is time we can ill
afford. Unlike Thrift, where methods live in relative isolation in
CassandraServer, everything in the CQL parser and QueryProcessor is
intertwined. So there is a higher price to pay than you may realize.
{quote}

Of course there is a balance to strike, and a cost to pay for maintaining
backward compatibility. But, we've used this argument for years and IMO people
are starting to expecting more from us now.

{quote}
But the longer we go before making necessary changes and finishing things, the
more painful that will get. So, to Eric's point, better to make these changes
now -- which I've been promising in public since at *least* Cassandra SF, so I
don't think it's valid to cry end-of-release foul -- than to make them for the
1.2 transition, when presumably more people will have deployed on CQL.
{quote}

I'm crying foul because we're proposing to break the language very late in the
game. How often people are expecting CQL to break notwithstanding, anyone who
has been trying to plan their projects around what they expect to land in 1.1
are in for a surprise. If no one is making such plans, then perhaps it's
because they've given up trying. Either way it's not good.

Doing this so late in the game, also increases the likelihood that something
will be missed and that things will need to change again later.

And I'm crying foul because this ticket was contentious and required a lot of
discussion to reach consensus (which I am _very_ thankful of when looking back
at what might have been implemented otherwise), and yet it seems we're all too
ready to pull the trigger on this potentially controversial errata without
taking it to the wider community.

I know this is publicly available, but you'd be hard pressed to do a better job
of obfuscating a discussion than having it in the comments of this issue.

{quote}
Let me elaborate. We're not actually removing functionality here. The new-style
definition of

{code}
CREATE TABLE foo (
key type1 PRIMARY KEY,
column type2,
value type3
) WITH COMPACT STORAGE
{code}

gives you the same freedom of using arbitrary column names as an old-style
declaration with a comparator of type2. The difference is, this definition
allows CQL queries to know how to turn the column name into a resultset value,
allowing it to be used in more flexible {{WHERE}} clauses than {{..}}, as well
as allowing use in paging across multiple rows (necessary for wide-row
map/reduce support).

So, we're not taking away the flexibility to use column names at run time for
non-composite columns; just requiring that if you want to use a CF in a
dynamic, wide-row way, you tell us about it so we can support you
appropriately. (Knowing when a CF is wide row oriented also opens up new
optimization possibilities, from simple ones like skipping the row-level bloom
filter to fancier ones like CASSANDRA-3581.)
{quote}

What is the effect on users with an existing schema?

{quote}
Hmm. I'm not sure if you misread what he said and thought he's changing it to
case-sensitive, or if you think case-sensitive is how it

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows

2012-01-13 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2474:
---

Setting aside any discussion of the specific changes being proposed for a 
moment, I would like to point out that I count at least 3 breaking changes to 
the language (a third new major language version in as many releases), that 
we're proposing making these changes late in the 11th hour of the release 
cycle, and without seeking input from the wider community (I can't imagine too 
many people are able to follow this issue any more).


 CQL support for compound columns and wide rows
 --

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Critical
  Labels: cql
 Fix For: 1.1

 Attachments: 0001-Add-support-for-wide-and-composite-CFs.patch, 
 0002-thrift-generated-code.patch, 2474-transposed-1.PNG, 
 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 
 2474-transposed-select.PNG, cql_tests.py, raw_composite.txt, 
 screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2012-01-11 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3634:
---

{quote}
It's more compelling to me when compared in the context of the existing RPC
performance. 5% is gain okay (PS vs RPC), but 16% (BB vs RPC) is a fairly
substantial improvement.

I was a little worried about the variance (even though the worst cases are
pretty close) but I ran some tests with the commit log disable and the
deviation is on par with the rest, I think it's just fast enough to push it
that hard.
{quote}

That's interesting. I got so wrapped up in the {{ByteBuffer}} vs. {{String}}
comparison that I lost track of the fact that your results put CQL w/ prepared
statements ahead of RPC _across the board_ (which is the most important
take-away from this I hope!). That would mean that you're willing to trade
that node-side abstraction for performance that is _already above-and-beyond_
RPC. I think I completely overestimated how compelling the
simplicity/abstraction vs performance trade-off argument would be to folks.

compare string vs. binary prepared statement parameters
---

Perform benchmarks to compare the performance of string and pre-serialized
binary parameters to prepared statements.

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2012-01-11 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3634:
---

{quote}
My reasoning is, there aren't a whole lot of places left to pick up an extra
10% performance... Two years ago, or one, maybe 10% isn't such a big deal since
there's so much left to optimize. That's no longer the case; I don't think we
should knowingly lock our next-gen interface into a lower-performing design.
Once made, we're stuck with this decision, or at least with a really, really
high barrier to change it.
{quote}

I think a custom protocol (planned for reasons unrelated to performance) could
easily be worth 10%. I take your point though, there isn't a lot of low
hanging fruit left.

{quote}
On the other hand, we have the downside of extra complexity for the driver
authors. While this is a valid point, it's a finite one – once a prepared
statement api has been created and debugged, binary vs strings isn't going to
matter. It's a one-time fee in exchange for better performance forever.
Additionally, sample binary marshalling code already exists for any language
with a Thrift driver. So we're really talking about a relatively small amount
of work to build a binary-based PS api, over a String one.
{quote}

I'm probably a little less optimistic about the amount of work or the potential
for bugs. A Pycassa bug that comes to mind caused integers to be mis-encoded
for more than a year before it was caught and fixed (and this being one of our
most (_the_ most?) battle-tested libraries).

That said, I do understand all of your points.

Considering the _kind_ of trade-off we're talking about, I wanted this issue to
be thoroughly thought through/discussed, with any relevant data readily at
hand. The scale is obviously quite different (I'm not citing a full swing of
the pendulum here), but the arguments for/against are basically the same ones
that spawned CQL in the first place. And, as you said, changing later is
prohibitively difficult; We're going to have to live with this decision.

I posted to client-dev@ earlier (I don't know why I didn't think of that a week
ago). They're basically our front-line users in this regard, and I think it
would be interesting to hear from some of them (particularly if I'm carrying a
mantle none of them care about :)).

compare string vs. binary prepared statement parameters
---

Perform benchmarks to compare the performance of string and pre-serialized
binary parameters to prepared statements.

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

2012-01-10 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2478:
---

{quote}
I don't see any other right off the bat, but between those two I would have a
slight preference for a custom protocol. My (to be honest not so extensive)
experience with HTTP is that it can be slowish and a tad annoying to work with
when you use it for something it wasn't designed for (typically streaming is
not a given). But a custom protocol will clearly be more work for us. I just
have a feeling that it may be worth it in the end.

And whether it is HTTP or custom, I've had good experience with Netty in the
past too.
{quote}

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.

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns

2012-01-10 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2474:
---

bq. Now if I'm the only one to think that maybe the PK notation may end up
being more confusing than helpful and does not convey important notion specific
to C*, then I'll shut up.

FWIW, I agree with you in principle. I've been involved in several such
discussions in the past and have always felt that strict adherence to SQL
syntax without adherence to SQL semantics was a double-edged sword. It's great
that it leverages what people already know, until it doesn't work they way they
_know_ it should.

But those discussions are in the past (where were you then? :)), and convention
has since become to adopt SQL syntax where possible, even if semantics differ.

What differs here is the degree by which this has the potential to surprise
people, and I do think this sets a precedence in that regard.

CQL support for compound columns

Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns

2012-01-06 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2474:
---

bq. Speaking of changing stuff, this makes WITH COMPARATOR and WITH VALIDATOR 
obsolete.

Are you saying this new {{CREATE COLUMNFAMILY}} syntax is a wholesale 
replacement for the previous one?

 CQL support for compound columns
 

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
  Labels: cql
 Fix For: 1.1

 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 
 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, 
 raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns

2012-01-06 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2474:
---

I guess what I'm asking is: Are you saying that {{WITH COMPARATOR}} is obsolete 
because there will be a Better Way, or because that syntax will no longer work?

 CQL support for compound columns
 

 Key: CASSANDRA-2474
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
  Labels: cql
 Fix For: 1.1

 Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG, 
 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG, 
 raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg


 For the most part, this boils down to supporting the specification of 
 compound column names (the CQL syntax is colon-delimted terms), and then 
 teaching the decoders (drivers) to create structures from the results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2012-01-06 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3634:
---

bq. for throughput, BB is consistently about 10% faster on inserts, and about
equal on reads, across all row types

Since there isn't anything here wildly inconsistent with my results, I'd
summarize it as ~10% faster on inserts, and about equal on reads, counter
increments, and index inserts.

bq. BB has substantially lower latency for large values on reads

I don't see how this test can be correct since the cost of parsing the query is
identical no matter how wide the rows are, or how large the values.

bq. something is fishy w/ BB stdev that might be worth investigating
(generating extra garbage somehow)?

This was consistent with what I saw as well, though for the life of me I can't
imagine what's causing it.

bq. 10% faster writes is a big enough deal that I'm in favor of committing the
BB version for 1.1.

It's not nearly so compelling to me. 10% is definitely on the high side of
making me stand up and take notice, but it's not enormous.

It's also limited to inserts, and requires that you completely saturate the
processors to make it evident at all, which is not a typical workload. That
doesn't make it irrelevant, just more relevant to those conducting benchmarks
than to real users.

On the other side, what's at stake is increased complexity for an arbitrary
number of clients, and a proven vector for bugs. And, to make this class of
bug even more interesting, it has the potential to make otherwise identical
queries return different results depending on whether they use the prepared
statement API, or the conventional one.

THAT BEING SAID: I've heard from enough people that were following the results
as they came in to know that most people (engineers?) have a hard time looking
past a simple faster/slower distinction, (even when the difference in question
was _much_ less than 10%). If others feel the same, that we should give up
this abstraction for 10% faster standard writes, then I won't belabor the point
further.

compare string vs. binary prepared statement parameters
---

Perform benchmarks to compare the performance of string and pre-serialized
binary parameters to prepared statements.

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns

2012-01-05 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2474:
---

bq. But at the risk of sounding like a buzzkill, I'd mention that this will be
tight and I don't think we should rush this (both code and review). That being
said, if there is no hiccup with the implementation we may be good.

I also think this is tight, particularly since it's introducing new syntax, and
a syntax that required one of the most (if not _the_ most) epic discussions.
Ever.

I've been thinking about this for a while, but what do people think about
implementing an experimental mode? Something that involves setting a boolean
in {{cassandra.conf}}, or passing a {{-Dcassandra.experimental=true}} property.

Code like this (or prepared statements for that matter) could test that
experimental mode is enabled, or raise a new Thrift exception if it isn't.

Granted that means we'll see less testing than we would otherwise, but I think
we stand to see more/better testing than we would from a beta or RC. More
importantly, it sets an expectation that it's new, less tested, and that
breaking changes might be coming (all of which are true IMO).

CQL support for compound columns

Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg

[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns

2012-01-05 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2474:
---

bq. -0 here, I don't think it really provides anything other than a CYA for us.
(We TOLD you it was experimental, you even had to turn on the option!)
Otherwise it's common sense that new-this-release features are going to be less
stable

I don't think it's about CYA, I see it as setting a clear expectation.

IMO (and recent experience bares this out), we can't in any confidence
introduce a new CQL feature like this without learning something after the
fact, and wishing we could go back and do it differently (or flat having no
choice). By that point, the Cat is out of the bag. Either we live with it
(and provide repeated explanations), or we fix it. Both of which are sources
of frustrations for users.

Some would say (have said) that we should do better QA to avoid this happening,
but there is only so much you can do without wider testing, and unfortunately
beta releases just don't cut it.

An experimental mode let's us Smoke Test a new feature like this while being
honest with our users that that's what we're doing. If we need to make
breaking changes, it gives us the freedom to do it (in this case without a CQL
major bump), because we've set that expectation. Users who value stability
were spared those landmines.

bq. ...it doesn't do much besides leave people just that much frustrated when
they go to try feature X and have to edit-and-bounce their server first.

I understand you probably meant s/edit-and-bounce/anything/, but we could also
make this settable though JMX and add a {{nodetool}} command for it (making a
skooch easier).

CQL support for compound columns

Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

2012-01-04 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3507:
---

bq. To sum up, my personal ideal solution would be to take cqlsh out of tree, 
along with cassandra-cli (and, actually, all the other bundled dependencies) 
and use package relationships to manage all that complexity (and just give 
tarball users a nice long installation readme).

+1

We could probably do better than a nice long installation readme though.  
Once, for a brief time, we were free of embedded dependencies.  Tarball users 
would fetch them with Ivy (that was before we were all mavened up).  Something 
like that could be done again for people who want to go about things the Hard 
Way.

bq. But if we want something built in to the main official C* tarball to allow 
talking to C* once it's running, I think we have to include cqlsh — based on 
the premise that the project wants cql to be the preferred mode of interface. 
If we include cassandra-cli but not cqlsh, cql will remain second-class. If we 
don't care about that, then yay, definitely we should leave cqlsh out.

I feel like I missed something important.  The description called for bundling 
a private copy of the driver.  This seems to be identical to how we currently 
handle all of our other external dependencies.  Is that off the table now?

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Blocker
  Labels: cql, cqlsh
 Fix For: 1.0.7


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key

2012-01-02 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3424:
---

Updated documentation:

https://github.com/eevans/cassandra/commit/a8d0135fe008dcb8754dcb9d5a173228bef30e0c
 (diff) https://github.com/eevans/cassandra/tree/3424 (branch)

 Selecting just the row_key returns nil instead of just the row_key
 --

 Key: CASSANDRA-3424
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: 3424-v2.txt, CASSANDRA-3424.patch


 CREATE KEYSPACE CassandraCQLTestKeyspace WITH 
 strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND 
 strategy_options:replication_factor=1
 USE CassandraCQLTestKeyspace
 CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY, 
 test_column text)
 INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test 
 string', 'test')
 # Works as expected
 SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
 # Returns an empty result, unexpected
 SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2011-12-30 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

I've re-run the tests with separate client and server, and included some new 
tests that should better expose the per-term processing costs.  Instead of 
ballooning this ticket with more inline graphs and tables, I'll just leave the 
link to my Google spreadsheet:

https://docs.google.com/spreadsheet/ccc?key=0AmAl6Pxmv6AndGxwMnFFaWtMOFVIUkdpbzVGYkptOWc

Raw results and plots are here: http://people.apache.org/~eevans/3634-1/

I look forward to comparing these with the tests Brandon is running.

 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3633) update stress to support prepared statements

2011-12-28 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3633:
---

The most current changes can be found here: 
https://github.com/eevans/cassandra/tree/3633.stress

 update stress to support prepared statements
 

 Key: CASSANDRA-3633
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3633
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1


 The {{stress}} utility needs to be updated for testing prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2011-12-28 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

To run these tests you need:

# https://github.com/eevans/cassandra/tree/3633.stress -- updates stress for 
prepared statements with String-typed args
# https://github.com/eevans/cassandra/tree/3634.bb -- updates Cassandra to use 
ByteBuffer-typed prepared statement args
# https://github.com/eevans/cassandra/tree/3634.stress.bb -- updates stress to 
use ByteBuffer args with prepared statements

Use branch #1 to test String arguments, and branches #2 and 3 when testing 
ByteBuffer arguments.

 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: stress-change-bind-parms-to-BB.patch, 
 v1-0001-CASSANDRA-3634-generated-thrift-code.txt, 
 v1-0002-change-bind-parms-from-string-to-bytes.txt


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2011-12-24 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3634:
---

bq. Let's get Brandon to do some testing on our cluster with separate clients
and servers.

I've started another run with one client, one server, but having another set of
results would be great, thanks.

bq. If strings are testing faster than binary then either

I don't think strings are faster. The differences between String and BB for
the insert-with-index, counter-increment, and read tests are very small, (i.e.
we're looking at #2 here).

I believe the reason the insert-with-index and counter increment tests would
fail to show a significant difference is because those operations push the
contention needle in a different direction. This is consistent with the fact
that vanilla CQL fares so much better against thrift on these tests. Also, the
counter increment test only has one bind var (the key), so I would expect the
difference to be quite small.

Like the counter increment test, the read test also only has one bind var
(again the key), so I would likewise expect any difference to be lost in the
noise.

The insert test above _does_ indicate some difference, BB beats out Strings by
4% (5 columns equates to 11 bind vars here). I don't have the results in front
of me, but I ran a new insert test last night and I believe this increases to
about 10% at 10x the number of columns.

The choice of initial tests here were based on what I had run earlier (to make
the obligatory before/after comparison). Those are still relevant I think, but
to get a better idea of BB vs String, we need some results for insert tests
with higher column counts (w/ client and server split to rule out #3 above).

compare string vs. binary prepared statement parameters
---

Attachments: stress-change-bind-parms-to-BB.patch,
v1-0001-CASSANDRA-3634-generated-thrift-code.txt,
v1-0002-change-bind-parms-from-string-to-bytes.txt

Perform benchmarks to compare the performance of string and pre-serialized
binary parameters to prepared statements.

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2011-12-23 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

v1-0001-CASSANDRA-3634-generated-thrift-code.txt and 
v1-0002-change-bind-parms-from-string-to-bytes.txt convert string bind params 
to binary for purposes of performance testing.

 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: v1-0001-CASSANDRA-3634-generated-thrift-code.txt, 
 v1-0002-change-bind-parms-from-string-to-bytes.txt


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2011-12-23 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

Here is the performance comparison.  I stuck to the same tests I performed 
earlier (those earlier results can be found  
[here|http://www.acunu.com/blogs/eric-evans/cql-benchmarking]).  The patches to 
support binary query parameters for Cassandra and {{stress}} are attached to 
this issue, and the raw results can be found [here| 
http://people.apache.org/~eevans/3634].

_Note: Percentages listed are in relation to RPC performance._

h3. Inserts, 20M rows x 5 columns

!http://people.apache.org/~eevans/3634/insert_20mx5_noidx_t50_20111223.png|width=700!

|| ||Average OP rate||Average Latency||
|RPC|23,681/s|1.1ms|
|CQL|21,128/s (-11%)|1.3ms (+11%)|
|CQL w/ Prepared statements|23,911/s|1.1ms|
|CQL w/ Prepared statements (binary parms)|24,919/s (+5%)|1.2ms (+5%)|


h3. Inserts, 10M rows x 5 columns, KEYS index

!http://people.apache.org/~eevans/3634/insert_10mx5_keysidx_t50_20111223.png|width=700!

|| ||Average OP rate||Average Latency||
|RPC|10,054/s|5ms|
|CQL|9,326/s (-7%)|5.4ms (+8%)|
|CQL w/ Prepared statements|10,413/s (+3%)|4.8ms (-3%)|
|CQL w/ Prepared statements (binary parms)|10,299/s (+2%)|5ms|


h3. Counter increments, 10M rows x 5 columns

!http://people.apache.org/~eevans/3634/count_10mx5_noidx_t50_20111223.png|width=700!

|| ||Average OP rate||Average Latency||
|RPC|22,075/s|1.2ms|
|CQL|20,645/s (-6%)|1.2ms (+2%)|
|CQL w/ Prepared statements|24,286/s (+9%)|1.2ms (-1%)|
|CQL w/ Prepared statements (binary parms)|23,359/s (+5%)|1.2ms|


h3. Reads, 20M rows x 5 columns

!http://people.apache.org/~eevans/3634/read_20mx5_noidx_t50_20111223.png|width=700!

|| ||Average OP rate||Average Latency||
|RPC|22,285/s|2.1ms|
|CQL|20,080/s (-10%)|2.3ms (+9%)|
|CQL w/ Prepared statements|22,374/s|2.1ms (-1%)|
|CQL w/ Prepared statements (binary parms)|22,176/s|2.1ms|


 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: stress-change-bind-parms-to-BB.patch, 
 v1-0001-CASSANDRA-3634-generated-thrift-code.txt, 
 v1-0002-change-bind-parms-from-string-to-bytes.txt


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2011-12-23 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

At Brandon's suggestion, I'm rerunning the insert test with some higher column 
counts.  That should make any per-term performance costs/savings more obvious.  
I'll post those results when I have them.

 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: stress-change-bind-parms-to-BB.patch, 
 v1-0001-CASSANDRA-3634-generated-thrift-code.txt, 
 v1-0002-change-bind-parms-from-string-to-bytes.txt


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters

2011-12-23 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3634:
---

No, it's not

 compare string vs. binary prepared statement parameters
 ---

 Key: CASSANDRA-3634
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
 Project: Cassandra
  Issue Type: Sub-task
  Components: API, Core
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: stress-change-bind-parms-to-BB.patch, 
 v1-0001-CASSANDRA-3634-generated-thrift-code.txt, 
 v1-0002-change-bind-parms-from-string-to-bytes.txt


 Perform benchmarks to compare the performance of string and pre-serialized 
 binary parameters to prepared statements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3397) Problem markers don't show up in Eclipse

2011-12-22 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3397:
---

I wasn't aware of this issue when I submitted (and later committed) 
CASSANDRA-3632.  Have you had the chance to try this again since?

CASSANDRA-3632 restored the default Java builder (so problem marks do show 
now), but I left the Ant Builder out entirely.  I personally found it too heavy 
to be running, for example, on every file save (I mash CTRL+S compulsively).  
Do you find the Ant Builder useful or were you primarily interested in 
restoring the error markers?

 Problem markers don't show up in Eclipse
 

 Key: CASSANDRA-3397
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3397
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 1.0.0
 Environment: Eclipse
Reporter: David Allsopp
Assignee: David Allsopp
Priority: Minor
  Labels: ant, eclipse, ide
 Fix For: 1.0.7

 Attachments: Cassandra-3397.patch


 The generated Eclipse files install an Ant Builder to build Cassandra within 
 Eclipse. This appears to mean that the default Java Builder is not present. 
 This means that no problem markers show up in the Problem view or the Package 
 Explorer etc when there are compiler errors or warnings  - you have to study 
 the console output, then navigate manually to the sources of the problems, 
 which is very tedious.
 It seems to be possible to re-install the default Java Builder in parallel 
 with the Ant Builder, getting the best of both worlds. I have documented this 
 on the wiki at http://wiki.apache.org/cassandra/RunningCassandraInEclipse
 I was wondering a) whether this can be done automatically by the 
 generate-eclipse-files Ant target, and b) whether using both Builders will be 
 problem if one is working on any of the generated code (Thrift, CQL etc). The 
 Java Builder can be temporarily disabled if so by unticking it under 
 Properties-Builders...
 See also https://issues.apache.org/jira/browse/CASSANDRA-2854

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key

2011-12-21 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3424:
---

OK, so stepping a back a bit...

If we have semantics which are stable and expected in some version, and we 
alter those in a future version (for anything other than a major version 
change), that is a regression.  So even if this patch had done what it intended 
to do, it would be a regression, and we have always fixed regressions as 
quickly as possible.

While it would make it no less of a regression, if this change had resulted in 
SQL semantics, it could be considered an improvement, but that is not the case. 
 The pre-3424 behavior at least benefits from being consistent with how the RPC 
interface works, and every prior CQL-enabled version of Cassandra.

So I believe we should revert this change because:
# It signals that we are serious about maintaining the contract we've made with 
our users
# The original behavior (while not ideal) better satisfies the element of 
least-surprise

 Selecting just the row_key returns nil instead of just the row_key
 --

 Key: CASSANDRA-3424
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: 3424-v2.txt, CASSANDRA-3424.patch


 CREATE KEYSPACE CassandraCQLTestKeyspace WITH 
 strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND 
 strategy_options:replication_factor=1
 USE CassandraCQLTestKeyspace
 CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY, 
 test_column text)
 INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test 
 string', 'test')
 # Works as expected
 SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
 # Returns an empty result, unexpected
 SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key

2011-12-21 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3424:
---

bq. I look at it this way: Are there more users of 1.0.0 .. 1.0.3 out there, 
who will be surprised when they upgrade to 1.0.7 if we leave it be?

Shouldn't we include the versions from the 0.8 series in this as well?

bq. Or users of 1.0.4 .. 1.0.6, who will be surprised when they upgrade if we 
change it? That's the most responsible way to signal we're taking stability 
seriously.

If you're suggesting that we fix regressions as soon as they are identified as 
such, instead of propagating them across 3 more releases because we prefer the 
new behavior, then I emphatically agree.

 Selecting just the row_key returns nil instead of just the row_key
 --

 Key: CASSANDRA-3424
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: 3424-v2.txt, CASSANDRA-3424.patch


 CREATE KEYSPACE CassandraCQLTestKeyspace WITH 
 strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND 
 strategy_options:replication_factor=1
 USE CassandraCQLTestKeyspace
 CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY, 
 test_column text)
 INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test 
 string', 'test')
 # Works as expected
 SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
 # Returns an empty result, unexpected
 SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3458) Add cqlsh to deb and rpm packaging

2011-12-21 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3458:
---

Committed with minor changes.

Specifically, the changes where to a) put a version on the {{python-support}} 
build dependency, and b) to use {{${python:Depends}} } in place of the 
hard-coded Python and {{python-support}} dependencies.

I don't think this makes any real difference for the platforms we're running 
on, but it's more inline with best practice 
(http://wiki.debian.org/Python/Policy), and maybe it'll make things more 
future-proof.

If you see any problems with this, let me know!

 Add cqlsh to deb and rpm packaging
 --

 Key: CASSANDRA-3458
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3458
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Affects Versions: 1.0.3
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.7

 Attachments: 3458.patch-debian.txt


 Once (if?) CASSANDRA-3188 is committed, cqlsh will be distributed with the 
 cassandra tarballs, but not in the debs or rpms. (Actually, it looks like the 
 cqlsh script will get put in the rpm by accident, but not its associated 
 libraries).
 We might even want to break cqlsh out into a separate package from the same 
 source, so that it can be installed on machines only intended to be used as 
 cassandra clients, not servers.
 Maybe that doesn't make sense without including nodetool and cassandra-cli 
 too, and then we'd need yet another package to hold the jars that are common 
 between cassandra and cassandra-client... maybe it's not worth it for now.
 Either way, make sure installing cassandra debs and rpms ends up with a 
 working cqlsh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3458) Add cqlsh to deb and rpm packaging

2011-12-21 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3458:
---

Oh, and I'm not sure if we should expect a patch to the RPM, so I'm leaving 
this open.  Feel free to close it if that's not happening.

 Add cqlsh to deb and rpm packaging
 --

 Key: CASSANDRA-3458
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3458
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging
Affects Versions: 1.0.3
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
 Fix For: 1.0.7

 Attachments: 3458.patch-debian.txt


 Once (if?) CASSANDRA-3188 is committed, cqlsh will be distributed with the 
 cassandra tarballs, but not in the debs or rpms. (Actually, it looks like the 
 cqlsh script will get put in the rpm by accident, but not its associated 
 libraries).
 We might even want to break cqlsh out into a separate package from the same 
 source, so that it can be installed on machines only intended to be used as 
 cassandra clients, not servers.
 Maybe that doesn't make sense without including nodetool and cassandra-cli 
 too, and then we'd need yet another package to hold the jars that are common 
 between cassandra and cassandra-client... maybe it's not worth it for now.
 Either way, make sure installing cassandra debs and rpms ends up with a 
 working cqlsh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3649) Code style changes, aka The Big Reformat

2011-12-20 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3649:
---

OCD (and low-res displays) notwithstanding, this change is going to Suck.  
Mightily.

Just saying.

 Code style changes, aka The Big Reformat
 

 Key: CASSANDRA-3649
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3649
 Project: Cassandra
  Issue Type: Wish
  Components: Core
Reporter: Brandon Williams
 Fix For: 1.2


 With a new major release coming soon and not having a ton of huge pending 
 patches that have prevented us from doing this in the past, post-freeze looks 
 like a good time to finally do this.  Mostly this will include the removal of 
 underscores in private variables, and no more brace-on-newline policy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3424) Selecting just the row_key returns nil instead of just the row_key

2011-12-20 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3424:
---

This change didn't do what it was supposed to, and it introduced a breaking CQL 
change, (which has since made it into stable release updates(!)).  If we'd have 
caught this before it was rolled into a release, I'd say it warranted an 
immediate -1 and a revert.

We haven't been doing nearly as well as I'd hoped in keeping stability 
promises, but I might be satisfied to call the original behavior buggy, and the 
intended behavior of this change as the fix, if it could be made to work the 
way intended (to return the result _if_ the row exists).  Can anyone see a way 
to accomplish that?

 Selecting just the row_key returns nil instead of just the row_key
 --

 Key: CASSANDRA-3424
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3424
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Kelley Reynolds
Assignee: Jonathan Ellis
Priority: Minor
  Labels: cql
 Fix For: 1.0.3

 Attachments: 3424-v2.txt, CASSANDRA-3424.patch


 CREATE KEYSPACE CassandraCQLTestKeyspace WITH 
 strategy_class='org.apache.cassandra.locator.SimpleStrategy' AND 
 strategy_options:replication_factor=1
 USE CassandraCQLTestKeyspace
 CREATE COLUMNFAMILY row_key_validation_cf_ascii (id ascii PRIMARY KEY, 
 test_column text)
 INSERT INTO row_key_validation_cf_ascii (id, test_column) VALUES ('test 
 string', 'test')
 # Works as expected
 SELECT * FROM row_key_validation_cf_ascii WHERE id = 'test string'
 # Returns an empty result, unexpected
 SELECT id FROM row_key_validation_cf_ascii WHERE id = 'test string'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-15 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2475:
---

bq. WFM. I assumed Rick had already implemented one for JDBC API completeness 
but if we're just going to no-op that out for now I'm not going to lose any 
sleep over it.

He did, but we removed it at an earlier stage of the review, for the reasons 
listed here (so if it's decided that we should have one, I'll do the work to 
put it back in).

bq. It's the client's responsibility to prepare the statements on each 
connection before using them, which implies some caching behavior on the part 
of the driver as in 
http://www.theserverside.com/news/1365244/Why-Prepared-Statements-are-important-and-how-to-use-them-properly

OK, that makes sense.  Though, it would seem to add another data-point to the 
API to remove PSes isn't necessary argument, since a close() on a pooled a 
connection isn't going to remove the statement server-side anyway.

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Affects Versions: 1.0.5
Reporter: Eric Evans
Assignee: Rick Shaw
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch, 
 2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt, 
 v1-0002-regenerated-thrift-java.txt, 
 v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt, 
 v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt, 
 v2-0003-eevans-increment-thrift-version-by-1-not-3.txt, 
 v2-0004-eevans-misc-cleanups.txt, 
 v2-0005-eevans-refactor-for-better-encapsulation-of-prepare.txt, 
 v2-0006-eevans-log-queries-at-TRACE.txt, 
 v2-0007-use-an-LRU-map-for-storage-of-prepared-statements.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-14 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2475:
---

OK, the attached v2-* patches are:

* v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt
* v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt

Rick's last, rebased against trunk as of today.

* 0003-eevans-increment-thrift-version-by-1-not-3.txt

Increment Thrift minor from 19 to 20, instead of 22

* 0004-eevans-misc-cleanups.txt

Various code cleanups

* 0005-eevans-refactor-for-better-encapsulation-of-prepare.txt

A refactoring of {{CassandraServer.prepare_cql_query}} and 
{{QueryProcessor.prepare()}} to encapsulate query preparation within 
{{QueryProcessor}} 

* 0006-eevans-log-queries-at-TRACE.txt

Log queries at TRACE.

* 0007-use-an-LRU-map-for-storage-of-prepared-statements.txt

Turn the Map that stores prepared statements into an LRU cache (currently 
evicts when size()  50)



Patches 3-6 are pretty minor and I would have just committed them as-is, but it 
wouldn't hurt to have someone (Rick?) else look at 7 (at least).

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Affects Versions: 1.0.5
Reporter: Eric Evans
Assignee: Rick Shaw
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch, 
 2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt, 
 v1-0002-regenerated-thrift-java.txt, 
 v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt, 
 v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt, 
 v2-0003-eevans-increment-thrift-version-by-1-not-3.txt, 
 v2-0004-eevans-misc-cleanups.txt, 
 v2-0005-eevans-refactor-for-better-encapsulation-of-prepare.txt, 
 v2-0006-eevans-log-queries-at-TRACE.txt, 
 v2-0007-use-an-LRU-map-for-storage-of-prepared-statements.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3505) Explicitly requested keys will always be present in resultset

2011-12-14 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3505:
---

This was introduced by https://issues.apache.org/jira/browse/CASSANDRA-3424

 Explicitly requested keys will always be present in resultset
 -

 Key: CASSANDRA-3505
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
 Project: Cassandra
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.3
Reporter: Cathy Daw
Assignee: Jonathan Ellis
Priority: Minor

 This bug is regarding the select after the 'truncate'.  In 1.0.1 no rows 
 would ever be returned, but now we are seeing a tombstone when querying for 
 user1.  Jake mentioned this may be related to CASSANDRA-2855. 
 {code}
 cqlsh CREATE KEYSPACE ks1 with 
...   strategy_class =  
... 'org.apache.cassandra.locator.SimpleStrategy' 
...   and strategy_options:replication_factor=1;
   
 cqlsh use ks1;
 cqlsh:ks1 
 cqlsh:ks1 CREATE COLUMNFAMILY users (
...   KEY varchar PRIMARY KEY, password varchar, gender varchar,
...   session_token varchar, state varchar, birth_year bigint);
 cqlsh:ks1 INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
 cqlsh:ks1 UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 
 'user1';
 cqlsh:ks1 SELECT * FROM users WHERE key='user1';
KEY | birth_year | gender |  password |
  user1 |   1980 |  m | ch@ngem3a |
 cqlsh:ks1 TRUNCATE users;
 // Expected, no rows returned
 cqlsh:ks1 SELECT * FROM users WHERE key='user1';
KEY |
  user1 |
 // Expected, no rows returned
 cqlsh:ks1 SELECT * FROM users;
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-14 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2475:
---

bq. Thanks Eric, for all the help and attention to detail! I learned a lot.
I'll be tuning up my formatter (Eclipse) to handle the nits of formatting and
white-space. And I'll try to break things up much finer in future large patches

Thank you for knocking this out!

bq. I'm still a bit iffy about having the server ditching entries in the
prepared statement map without regard to whether the client side closed the
associated PreparedStatement. But like you, I think the chances of ever seeing
50 entries without closing the connection are slim.

Think about it this way: whether or not the client removes unused entries, it's
still prudent to put a limit on the number of statements we cache, otherwise a
buggy client could eat up our heap. And, if you're going to put something in
place to evict, choosing the least recently accessed seems like the safest
approach.

The question then becomes, how many can we afford to hang onto, and what is the
likelihood that, short of a buggy client, we won't be able to accommodate
everything needed. Remember, this is only for the life of a connection,
reconnecting starts a whole new Map. So if an API to remove entries is
ultimately of little to no benefit, then we should save everyone the trouble of
implementing and maintaining it.

And, we could always take this to a wider audience to see what others think,
but it's easier to add something like this later than it is to remove (or fix)
it.

Also, 50 might not be the right number. I basically pulled that out of my butt.

Prepared statements
---

Key: CASSANDRA-2475
URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Affects Versions: 1.0.5
Reporter: Eric Evans
Assignee: Rick Shaw
Priority: Minor
Labels: cql
Fix For: 1.1

Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch,
2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt,
v1-0002-regenerated-thrift-java.txt,
v2-0001-CASSANDRA-2475-rickshaw-2475-v3.1.patch.txt,
v2-0002-rickshaw-2475-v3.2-Thrift.patch-w-changes.txt,
v2-0003-eevans-increment-thrift-version-by-1-not-3.txt,
v2-0004-eevans-misc-cleanups.txt,
v2-0005-eevans-refactor-for-better-encapsulation-of-prepare.txt,
v2-0006-eevans-log-queries-at-TRACE.txt,
v2-0007-use-an-LRU-map-for-storage-of-prepared-statements.txt

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-14 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2475:
---

bq. If a client is doing it right, then it will use pooled connections, each
of which will use PS for each query needed by the app. Hundreds or even
thousands isn't crazy. So I'd be okay with a limit of 1 as practically
equivalent to unlimited for all intents and purposes, but it might save you
from a buggy client.

OK. The second half of that is, how many of those hundreds or even thousands
will you want to remove during the life of a connection. For every application
I could think of, I picture, like you say, a pool of connections that contain a
PS for each query needed. The cases where you would no longer need a PS for
the life of a connection seems exceptional enough that there would be no harm
in keeping it.

I'm not fundamentally opposed to an API call to remove PSes, I'm just trying to
keep things simpler if it doesn't actually provide any value.

But this raises something I hadn't considered. Storing prepared statements per
connection seems like it could make things awkward. If you want to access a PS
on an arbitrary connection pulled from a pool, then you're going to need some
way of dealing with a connection that doesn't have that PS stored. Likewise,
if we have an API for removing them, then you'd need to iterate all open
connections to remove the others. Or am I missing something?

Prepared statements
---

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-12 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2475:
---

Thank Rick; I think we're getting closer.

I was going to run the tests in the {{new-prepared}} branch of the JDBC driver, 
but had problems figuring out how to build it, then realized that it needed 
changes for {{CqlBindValue}} and {{CqlResultType}}, but had problems getting it 
setup in eclipse (thrift not on the class path).

I'll try to get back to this tomorrow, but if you have any time to look at this 
in the meantime, that would be great.


 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Affects Versions: 1.0.5
Reporter: Eric Evans
Assignee: Rick Shaw
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: 2475-v1.patch, 2475-v2.patch, 2475-v3.1.patch, 
 2475-v3.2-Thrift.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt, 
 v1-0002-regenerated-thrift-java.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-09 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2475:
---

{quote}
But then I hated the idea of having to go to HEX to get in blob/bytes data.
This approach let me do both. It also allowed me to serialize Java Objects
nicely as bytes. Can you think of a clever way to handle byte streams
(AbstractBytes)? But I can live with just String. I agree it is the most
flexible.
{quote}

Believe it or not, between ASCII strings and hex encoded blobs, the latter is
cheaper to decode node-side.

{quote}
It allows you to free the cached {{CQLStatement}} on the server side when a
client side PreparedStatement is closed. If not, you will accumulate dead
entries until the connection is closed. That could be a lot of dead wood.
Seemed the tidy thing to do.
{quote}

So, my initial thought (and what led me to ask this), was that in practice, the
number of prepared statements per active connection is probably quite low. Low
enough that there would never be any reason to evict. You probably wouldn't
want to bet the farm on that though, so I had thought it would probably make
some sense to have a threshold that would cause statements to be evicted when
new ones were added (on an LRU-basis).

This seems to have the advantage that would make the interface simpler. It
would also be less error prone; Relying on the client to free resources seems a
bit brittle.

What do you think?

bq. The count is to know how many markers were actually encountered. This
number serves as the upper bound for Setxxx parameter indexes. Better than
regexing for it... it is exactly what the server side encountered.

{quote}
The statement type is again a validation of what the server side saw. Remember
this happens in 2 steps prepare then execute, and the execute step does not
have the CQL text.
But I used it while debugging and I don't seem to use it any more so I guess it
could go, but it I thought I might find a use for is so I never did make it go
away.
{quote}

It's probably best to avoid without a raison d'etre. Things like this are
easier to add later, than they are to remove once they've made it into release.

bq. Another seems useful so I kept it around. If something goes wrong and you
need to go poking around its handy to have attached to the statement (I think).

I worry that it might be wasteful. Especially if we do need to worry about the
number of statements we keep for each connection.

Query logging can be used to capture the verbatim string for troubleshooting
purposes, and all of the data should still be there in the form of the graph of
objects. Is there some known case that doesn't cover?

bq. I think there was already an instance there at DEBUG and I just added some
more. I'll gladly move to TRACE.

The way it was originally, the statement type (SELECT, UPDATE, etc) was logged
at level DEBUG, and the entire query was logged at TRACE. If there isn't a
reason to change, we should probably keep it that way.

bq. The short answer is because the question marks are often referred to in
the spec as bound variable markers. So I just propagated it. But NBD to
change to bind theme.

OK. Yeah, even say {{indexBindMarkers}} would be good. I was just thinking
that markers was a bit generic there.

Prepared statements
---

Attachments: 2475-v1.patch, 2475-v2.patch,
v1-0001-CASSANDRA-2475-prepared-statement-patch.txt,
v1-0002-regenerated-thrift-java.txt

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-09 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-2475:
---

{quote}
While I agree in principle, from CASSANDRA-1788, CASSANDRA-, and others,
we've seen that reducing copies really matters to CPU-bound queries. So I would
expect the same here; convert-from-string is basically a glorified copy.
{quote}

Is it more expensive to parse them as strings? Sure, but evaluating the
cost-to-benefit could be difficult enough _without_ guessing at what that cost
is. :) Whether it's preserialized binary, or string, it should be one or the
other and it sounds like no one is in disagreement there. Testing it both ways
should be very easy, so I suggest we revisit this part of the discussion (if
necessary) after we have some real data.

bq. We're already doing binary data for resultsets, so I don't think the bar
for client developers gets much higher if we use them for prepared statements.

If by bar you mean skills/capabilities, then sure, but that wasn't my concern.

Serializing _to_ bytes is a Whole Other Thing, it's not as if already doing the
one, is going to make doing the other any easier/less error-prone. It's also
two very different vectors for bugs, multiplied by the number of client
implementations. And, it is very different than deserializing results which
can only happen one way, a serialization bug could mean that
{{execute_cql_query()}} and {{execute_prepared_cql_query()}} do very different
things with the same query.

Prepared statements
---

Attachments: 2475-v1.patch, 2475-v2.patch,
v1-0001-CASSANDRA-2475-prepared-statement-patch.txt,
v1-0002-regenerated-thrift-java.txt

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-08 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2475:
---

Alright.  This one is sort of a monster, so bare with me if any of this seems 
disorganized, or jumps around. Also, if it seems long(ish), don't be 
disheartened, again, it's a bit of a monster; All-in-all it looks pretty good.

First, on the subject of patch submission, coding conventions, etc:

If at all possible, try to break a large change like this into more than one 
changeset, with logically separate changes in separate patches.  A work-flow 
based on patch submission sucks, I know, but Git can make this fairly easy (you 
mentioned you were using Git).  It definitely makes review easier and is much 
appreciated.

That said, don't worry about breaking this one into smaller patches (something 
to keep in mind for next time).

Also, avoid unnecessary changes to whitespace, or unrelated/cosmetic changes.  
They add noise to the review and increase the likelihood of collisions when 
merging or rebasing.  A bit here and there is fine, but if you do any sort of 
substantive cleanup, roll that up into a separate patch.

Some specific code-style/convention nits:
* Consensus seems to be against {{SuppressWarnings}} annotations, or the use of 
{{Override}} for interfaces
* Put a space between method arguments
* When wrapping a method call, align the arguments with the open paren

OK, on to the bigger fish.

There was some earlier discussion in this ticket about using preserialized 
binary parameters, or strings that would be parsed node-side.  Which of those 
two views is right notwithstanding, I feel pretty strongly that a struct that 
can optionally do either, is the wrong choice.  Let's not make this 
implementation, or the client-facing interface any more complicated than it 
needs to be.

My opinion on string vs. binary is largely unchanged here.  String parameters 
is the path of greatest abstraction, eliminating a proven vector for bugs, and 
it keeps our query interface as friendly as possible.  

That said, if the performance advantage to preserialized values were known, and 
turned out to be significant enough, I'd happily reconsider (I like fast as 
much as the next guy).  My suggestion then would be this:  Let's refactor this 
patch to type the variables as {{String}} and get it in-tree.  From there, it's 
a simple matter of a patch to change from {{String}} to {{ByteBuffer}} (and of 
course to drop the {{AT.fromString}}), and we can run some benchmarks.  I will 
commit to working up this latter patch, and to the benchmarking, within the 
time remaining to 1.1, if that helps.

Other questions and concerns in no particular order:

* Does {{remove_prepared_query}} support something particular in JDBC (or any 
other standard)?  How will that be used?
* With regard to {{CqlPreparedResult}}:
** What is the purpose of the count that is returned?  How is that used?
** What is the purpose of the {{CqlStatementType}} returned.  How will that be 
used?
* Is {{CQLStatement.cql}} only used for logging?  If so, should we be keeping a 
copy of the query string around for that?  Maybe we could create a {{toString}} 
that would descend to create the query (or something comparable).
* There are a few places where queries are being logged at DEBUG.  That seems 
too verbose for DEBUG.
* Why is {{Term.bindIndex}} marked as volatile?
* In {{CassandraServer.prepare_cql_query}}, don't create a separate variable 
for state
* Not a biggie, but how about using bind or bound instead of mark when 
referring to term position? i.e. {{needsBind}} instead of {{isMarked}}, or 
{{indexBindTerms}} instead of {{discoverMarkedTerms}}
* {{QueryProcessor.prepare}} seems as though it could be folded into  
{{CassandraServer.prepare_cql_query}}
* It seems as though {{QueryProcessor.doTheStatement}} and 
{{QueryProcessor.process}} could be merged into one method.

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Affects Versions: 1.0.5
Reporter: Eric Evans
Assignee: Rick Shaw
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: 2475-v1.patch, 2475-v2.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-2475) Prepared statements

2011-12-08 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-2475:
---

Since I had to rebase a couple of times (and resolve conflicts), I've attached 
patches from my repository if that helps.

 Prepared statements
 ---

 Key: CASSANDRA-2475
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
 Project: Cassandra
  Issue Type: New Feature
  Components: API, Core
Affects Versions: 1.0.5
Reporter: Eric Evans
Assignee: Rick Shaw
Priority: Minor
  Labels: cql
 Fix For: 1.1

 Attachments: 2475-v1.patch, 2475-v2.patch, 
 v1-0001-CASSANDRA-2475-prepared-statement-patch.txt, 
 v1-0002-regenerated-thrift-java.txt




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3570) barrier-of-entry: make ./bin/cassandra -f work out of the box by changing default cassandra.yaml

2011-12-03 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3570:
---

bq. Yes, I am aware that you can over-ride the configuration but honestly,
that's just painful. Especially when switching between various versions of
Cassandra.

Just playing Devil's advocate here, but is this really optimizing for the
new/first-time users, or for someone who does a lot of ad hoc testing?

barrier-of-entry: make ./bin/cassandra -f work out of the box by changing
default cassandra.yaml

Key: CASSANDRA-3570
URL: https://issues.apache.org/jira/browse/CASSANDRA-3570
Project: Cassandra
Issue Type: Improvement
Reporter: Peter Schuller
Assignee: Peter Schuller
Priority: Trivial
Attachments: CASSANDRA_3570-dbpath.txt

This is probably going to be controversial. But how about the attached simple
patch to just have ./db exist, and then have Cassandra configured to use that
by default? This makes it a lot easier for people to just run Cassandra out
of the working copy, whether you are a developer or a user who wants to apply
a patch when being assisted by a Cassandra developer.
A real deployment with packaging should properly override these paths anyway,
and the default /var/lib stuff is pretty useless. Even if you are root on the
machine, who it is much cleaner to just run self-contained.
Yes, I am aware that you can over-ride the configuration but honestly, that's
just painful. Especially when switching between various versions of Cassandra.

[jira] [Commented] (CASSANDRA-3527) Expose JMX values via CQL interface

2011-12-02 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3527:
---

bq. It gives you human readable html and an ugly – but serviceable – XML based 
api. It's probably not what most people would expect if you said 'rest'.

I didn't know that, but it makes sense based on their objectives.  A simple 
rest interface wouldn't be enough to fully exploit JMX.

 Expose JMX values via CQL interface
 ---

 Key: CASSANDRA-3527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Kelley Reynolds
Priority: Minor
  Labels: cql



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3527) Expose JMX values via CQL interface

2011-11-28 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3527:
---

For The Record: There have been _many_ complaints about that Java requirement 
that JMX imposes.  I do think we should solve this (hence the 
questions/proposals above).

 Expose JMX values via CQL interface
 ---

 Key: CASSANDRA-3527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Kelley Reynolds
Priority: Minor
  Labels: cql



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3527) Expose JMX values via CQL interface

2011-11-28 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3527:
---

bq. I think Kelley made a good point that being able to do everything with a 
single interface is much friendlier than the current state. It will be Yet 
Another Way, sure, but I think a unified interface will help drive adoption.

See, abuse of the CQL interface notwithstanding, I don't really see it as a 
feature to have this All-in-one (see my remarks above about separation of 
concerns).

And, easiest doesn't necessarily equate to Right.  By way of example, a 
password-less login is way easier than having to remember a password and type 
it in at login, but you wouldn't forgo authentication entirely just to make 
things easier.

 Expose JMX values via CQL interface
 ---

 Key: CASSANDRA-3527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Kelley Reynolds
Priority: Minor
  Labels: cql



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3527) Expose JMX values via CQL interface

2011-11-25 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3527:
---

This has come up many times before (in the past it was Thrift), and while I 
recognize the desire people have to access instrumentation without using Java, 
this seems like a bad idea.  Right now we have an excellent separation of 
concerns, and the only reason I can think of for suggesting this is because 
it's the only other hammer at hand.

I've never looked at it closely, but we added hooks for using an HTTP adapter 
with mx4j specifically to address this issue.  Does anyone know why that hasn't 
caught on?

It's also supposed to be possible to have the JVM present an SNMP interface.  I 
haven't tried doing that either, but it seems appealing considering the huge 
number of tools that already work with SNMP out of the box.

At Acunu, we have a service that acts as a bridge to JMX and presents a simple 
socket-based API similar to memcache which I could upstream.  Would that solve 
the problem for people?

 Expose JMX values via CQL interface
 ---

 Key: CASSANDRA-3527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Kelley Reynolds
Priority: Minor
  Labels: cql



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3527) Expose JMX values via CQL interface

2011-11-25 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3527:
---

bq. I wouldn't say this would solve a problem that can't be solved some other 
way, it would just be nice. Adding some SNMP and HTTP and Memcache isn't 
related to whether or not all tasks can be accomplished with the same protocol 
which is what I was after.

How Postgres does things notwithstanding, I don't see it as a feature to put 
everything under one interface like this.  It's two very different types of 
data, that serve very different purposes.

 Expose JMX values via CQL interface
 ---

 Key: CASSANDRA-3527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Kelley Reynolds
Priority: Minor
  Labels: cql



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3527) Expose JMX values via CQL interface

2011-11-25 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3527:
---

The delineation is that one is for manipulation of data (and schema), and the 
other is for management.  There may or may not be a few inconsistencies there, 
but that doesn't invalidate the entire approach.

And, it's really not inertial either.  There have been some very specific 
discussions in the past about where something should go and why, and in the end 
the outcome was generally consistent with what I've said here.

 Expose JMX values via CQL interface
 ---

 Key: CASSANDRA-3527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Kelley Reynolds
Priority: Minor
  Labels: cql



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3527) Expose JMX values via CQL interface

2011-11-25 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3527:
---

Some other questions:

Is this supposed to be a complete replacement for JMX?  And if so, how 
realistic is that without regressions?  Will it support operations?  Will it 
return all of the attributes, even the complex types?

How will it be implemented?  Are we going to have to edit the grammar each time 
we add new instrumentation?  If it's not a complete replacement, then are we 
going to have to update/create the MBean interfaces _and_ update the grammar?

If it's not meant to be a complete replacement, then how will this not 
contribute to there being even _more_ ways getting at the same data?



 Expose JMX values via CQL interface
 ---

 Key: CASSANDRA-3527
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
 Project: Cassandra
  Issue Type: New Feature
  Components: Core
Reporter: Kelley Reynolds
Priority: Minor
  Labels: cql



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3498) Add same-row contention mode to stress tool

2011-11-24 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3498:
---

I used -L in https://issues.apache.org/jira/browse/CASSANDRA-2268 (patches will 
be along shortly) for --enable-cql.  Are there any other short options we could 
use for this?

 Add same-row contention mode to stress tool
 ---

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

 Attachments: CASSANDRA-3498.patch


 For CASSANDRA-2893 and other scenarios we'd like to generate non-unique rows 
 to insert.  (Maybe we can re-use the same pseudorandom distribution code we 
 already have for reads.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers

2011-11-21 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3507:
---

This would be an improvement over the current situation I think.

bq. Maybe we even ought to take some minor steps to discourage its use for 
other purposes.

One option would be to script generate some obfuscation.  This could be as 
simple as prepending (or appending) something to each of the methods.

 Proposal: separate cqlsh from CQL drivers
 -

 Key: CASSANDRA-3507
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
 Project: Cassandra
  Issue Type: Improvement
  Components: Packaging, Tools
Affects Versions: 1.0.3
 Environment: Debian-based systems
Reporter: paul cannon
Assignee: paul cannon
Priority: Minor
  Labels: cql, cqlsh
 Fix For: 1.0.4


 Whereas:
 * It has been shown to be very desirable to decouple the release cycles of 
 Cassandra from the various client CQL drivers, and
 * It is also desirable to include a good interactive CQL client with releases 
 of Cassandra, and
 * It is not desirable for Cassandra releases to depend on 3rd-party software 
 which is neither bundled with Cassandra nor readily available for every 
 target platform, but
 * Any good interactive CQL client will require a CQL driver;
 Therefore, be it resolved that:
 * cqlsh will not use an official or supported CQL driver, but will include 
 its own private CQL driver, not intended for use by anything else, and
 * the Cassandra project will still recommend installing and using a proper 
 CQL driver for client software.
 To ease maintenance, the private CQL driver included with cqlsh may very well 
 be created by copying the python CQL driver from one directory into 
 another, but the user shouldn't rely on this. Maybe we even ought to take 
 some minor steps to discourage its use for other purposes.
 Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3188) cqlsh 2.0

2011-10-30 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3188:
---

bq. Because it's a core part of the distribution, or will be. By analogy, it 
would feel wrong for psql to be a separate project from postgresql core.

So it sounds like you're saying that we need it to satisfy the ships with a 
client shell requirement.  That's fine with me, but brace yourself for the 
impending criticism that the requirement isn't met, (because it requires 
separate installation of the module). :)

 cqlsh 2.0
 -

 Key: CASSANDRA-3188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3188
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jonathan Ellis
Assignee: paul cannon
 Fix For: 1.0.2

 Attachments: 3188.patch4.txt


 I'd like to see some improvements to cqlsh to bring it to feature parity w/ 
 the old cli:
 - describe [KS | CF | cluster | schema]
 - assume
 - connect / don't crap out w/ stacktrace if C* isn't currently running on 
 localhost
 - help
 It may be easier to do this by forking the cli and replacing its one-off api 
 with CQL, or it may be easier to add these features to cqlsh.
 Either is fine, but if it's a close call my inclination would be to build it 
 in Java for the reasoning over on CASSANDRA-3010.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3188) cqlsh 2.0

2011-10-29 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3188:
---

bq. I'd like cqlsh in the C* tree, but I'm totally fine with saying to run 
this, easy_install cassandra-dbapi. If you want to get fancy, we can even 
print that on an import exception.

For curiosity sake, why is that?  Is it just to make it obvious what we expect 
people to use?

 cqlsh 2.0
 -

 Key: CASSANDRA-3188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3188
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jonathan Ellis
Assignee: paul cannon
 Fix For: 1.0.2

 Attachments: 3188.patch4.txt


 I'd like to see some improvements to cqlsh to bring it to feature parity w/ 
 the old cli:
 - describe [KS | CF | cluster | schema]
 - assume
 - connect / don't crap out w/ stacktrace if C* isn't currently running on 
 localhost
 - help
 It may be easier to do this by forking the cli and replacing its one-off api 
 with CQL, or it may be easier to add these features to cqlsh.
 Either is fine, but if it's a close call my inclination would be to build it 
 in Java for the reasoning over on CASSANDRA-3010.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3188) cqlsh 2.0

2011-10-28 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3188:
---

Wow, this looks nice; Great work Paul!

We should publish the doc on the website (I can do that when it's committed if 
someone doesn't beat me to it).

Also, since this requires the Python module, will it be going into that tree, 
or into Cassandra's?  Either way, we should probably include some kind of 
installer.

 cqlsh 2.0
 -

 Key: CASSANDRA-3188
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3188
 Project: Cassandra
  Issue Type: Improvement
Reporter: Jonathan Ellis
Assignee: paul cannon
 Fix For: 1.0.2

 Attachments: 3188.patch4.txt


 I'd like to see some improvements to cqlsh to bring it to feature parity w/ 
 the old cli:
 - describe [KS | CF | cluster | schema]
 - assume
 - connect / don't crap out w/ stacktrace if C* isn't currently running on 
 localhost
 - help
 It may be easier to do this by forking the cli and replacing its one-off api 
 with CQL, or it may be easier to add these features to cqlsh.
 Either is fine, but if it's a close call my inclination would be to build it 
 in Java for the reasoning over on CASSANDRA-3010.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3420) test run from ant

2011-10-28 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3420:
---

Verbose isn't a problem for me (but maybe I'm just spoiled by command 
completion). How about {{run-test-mode}}, or {{test-run}}?  Those seem to make 
it patently obvious what it does.

 test run from ant
 -

 Key: CASSANDRA-3420
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3420
 Project: Cassandra
  Issue Type: Improvement
  Components: Core, Tests
Affects Versions: 1.0.0
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
 Attachments: v1-0001-CASSANDRA-3420-run-cassandra-from-ant.txt


 We have everything all setup to run a test node on localhost:9170, why not 
 create an ant target to do that?
 Patch to follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3397) Problem markers don't show up in Eclipse

2011-10-23 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3397:
---

This has annoyed me as well, so if there are no landmines associated with 
enabling both builders, I'd be in favor of it.

 Problem markers don't show up in Eclipse
 

 Key: CASSANDRA-3397
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3397
 Project: Cassandra
  Issue Type: Bug
  Components: Packaging
Affects Versions: 1.0.0
 Environment: Eclipse
Reporter: David Allsopp
Priority: Minor
  Labels: ant, eclipse, ide

 The generated Eclipse files install an Ant Builder to build Cassandra within 
 Eclipse. This appears to mean that the default Java Builder is not present. 
 This means that no problem markers show up in the Problem view or the Package 
 Explorer etc when there are compiler errors or warnings  - you have to study 
 the console output, then navigate manually to the sources of the problems, 
 which is very tedious.
 It seems to be possible to re-install the default Java Builder in parallel 
 with the Ant Builder, getting the best of both worlds. I have documented this 
 on the wiki at http://wiki.apache.org/cassandra/RunningCassandraInEclipse
 I was wondering a) whether this can be done automatically by the 
 generate-eclipse-files Ant target, and b) whether using both Builders will be 
 problem if one is working on any of the generated code (Thrift, CQL etc). The 
 Java Builder can be temporarily disabled if so by unticking it under 
 Properties-Builders...
 See also https://issues.apache.org/jira/browse/CASSANDRA-2854

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3380) REST Layer

2011-10-20 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3380:
---

{quote}
... but thinking about it, I don't think that's really a big deal unless you're
building a data browser. As an app author, you presumably already know that
user['photo'] is a blob, and as a curl user, you don't care a great deal
whether '4c330d52-5f8e-4084-918c-8dd727014ab9' is a time or a lexical uuid, or
possibly just a string that looks like one.
{quote}

A better way of stating it is, without layering schema (and the associated
client-side code), then you're forced into a world of strings. For something
things this makes no difference, for others it does. Brian's examples and
use-cases are decidedly biased toward applications that use strings everywhere.

My point was that once you resort to schema in order to make it generally
useful, then then the benefits cited are moot. If your application relies on
the size of an integer, or needs access to the time component of a uuid, or
uses composite or custom types, then speaking http + json won't be enough to
integrate with other systems, and using curl will be a lot more involved. If
you're going to layer schema on REST, you're much better off to just use CQL.

REST Layer
---

Key: CASSANDRA-3380
URL: https://issues.apache.org/jira/browse/CASSANDRA-3380
Project: Cassandra
Issue Type: New Feature
Environment: Unix / Max OS X
Reporter: Brian ONeill
Attachments: trunk-3380.txt

This is a native rest layer for Cassandra implementing
AbstractCassandraDaemon.
It uses JAX-RS fueled by Apache CXF.
Presently it supports the following operations JSON over HTTP:
- Create keyspace
- Drop keyspace
- Create column family
- Drop column family
- Insert row
- Fetch row
- Delete row
- Insert column
- Delete column
- Fetch column
The patch creates a new project in contrib/rest. You can compile the project
using ant, which uses ivy to pull in dependencies. To get setup, you can
also use the pom.xml file and m2eclipse to get it into Eclipse.
Once compiled, simpy run bin/rest_cassandra and follow along in the
README.txt

[jira] [Commented] (CASSANDRA-3380) REST Layer

2011-10-19 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3380:
---

Hi Brian,

I've only briefly glanced over the code, but what I see looks good. It's great
that you've already taken care of things like build and docs.

However, I'm not sure where (or even if )this should live within Cassandra.
contrib/ would be the right place I think, except that we're in (have been) in
the process of trying to eliminate that.

And, the impetus for removing contrib/ was that it was a place of second-class
citizenship, with mixed expectations that didn't reflect well on Cassandra, or
the authors of the contributed code. In other words, it should either by fully
supported, or maintaining it out of tree is probably in everyone's best
interest.

Have you considered maintaining this as a separate project? It seems as though
it would be pretty easy, logistically speaking.

REST Layer
---

[jira] [Commented] (CASSANDRA-3380) REST Layer

2011-10-19 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3380:
---

{quote}
I agree. As it stands, the elementary interface that is implemented thus far
hides some of the rich types, but I would expect that we would continue to
enhance the layer to provide access to those rich types and it would end up
much like how SOLR exposes the underlying features and functions of Lucene via
its REST interface
{quote}

How are you going to implement Cassandra's type system without implementing
schema? Once you drag schema into the mix, how will you justify this approach
when it's no longer possible to plug-and-play existing systems, or drive
queries with curl?

{quote}
As for demand, I think there is significant interest; enough to spawn up
projects:

http://code.google.com/p/restish/
https://github.com/stinkymatt/Helena
http://www.onemanclapping.org/2010/09/restful-cassandra.html
https://github.com/gdusbabek/cassandra
{quote}

I believe the project in that first link is from Courtney Robinson, and I
believe that he now advocates CQL (he started work on a CQL driver, and stopped
working on that). I'm not sure what the story is behind the second link, other
than it doesn't appear to have generated much interest (based on forks and
watchers).

The last two links are both from Gary Dusbabek (a member of the Cassandra PMC).
This was a proof-of-concept that he only spent a few hours on, and one that he
decided not to continue with. It might be worth asking him why.

Honestly, I think this does more to prove why a REST interface _does not_
belong integrated in Cassandra.

It is not enough to simply have code. That code needs to be maintained, and it
needs more than one person who cares enough to make sure that happens. It also
needs to be documented, and supported on all the usual forums, again, something
that will requires a little more critical mass

And, introducing choice can be a Good Thing, but it can also be a Bad Thing.
We need to know that this is going to be useful enough, to a large enough
audience, to offset the confusion it will almost certainly generate. Think of
the people who are going to be compelled to ask which interface they should
use, and who are going to have to weigh the pros and cons and then make a
choice (and remember that this would bring us from 2, to 3 choices of
interface). Think of the users who are going to make assumptions about
semantics or performance characteristics based on one interface or the other,
only to find it's not applicable to their choice.

There is a cost associated with this, and it's fair to ask the hard questions
to make ensure it's worth it.

You've also repeatedly alluded that not having this accepted as part of the
project is something of a deal breaker. Why? Now that you have this code,
doesn't it solve your particular needs?

I won't veto this if consensus is that it should be added, but I'm still not
convinced that this will succeed where the other attempts have failed. Nor am
I convinced that the only way to establish success is by committing it first.
What would convince me is a moderately successful externally maintained
project, with a modicum of users.

REST Layer
---

[jira] [Commented] (CASSANDRA-3380) REST Layer

2011-10-19 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3380:
---

{quote}
Acceptance is certainly not a deal breaker. Like you said, this code solves our
needs and we'll continue to extend it. I can throw it out into an open source
project to see if it sticks. Any preferred forum for that project?
{quote}

We recently moved drivers to external projects maintained on Apache Extras
(http://code.google.com/a/apache-extras.org/hosting). We put them there mostly
for branding purposes. Other than that, I'd stick with whatever works best
and/or is easiest for you.

{quote}
(One final note that I posted today to the user list; we could potentially use
this REST layer as an integration point for Elastic Search, much the way
CouchDB integrated as a river,
http://www.elasticsearch.org/tutorials/2010/08/01/couchb-integration.html. We
may try to head that way depending on what is available in DataStax Enterprise.
I'll let you guys know if that manifests itself.)
{quote}

Sure. Enabling a new and interesting use-case would also be a great validator.

REST Layer
---

[jira] [Commented] (CASSANDRA-3300) relocate Java (JDBC) CQL driver

2011-10-13 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3300:
---

bq. Well ideally the cassandra-clientutil.jar needs to be set up to publish to
Maven central... and there is also the question of publishing the JDBC driver
to Maven central.

OK, but that should be a separate ticket, and not something that blocks this
one, (it's something that would need to be done whether the driver was moved or
not).

This ticket is technically done, the only thing remaining is to actually remove
the {{drivers/}} directory, and of course, the build and test targets from
{{build.xml}}.

relocate Java (JDBC) CQL driver
---

Key: CASSANDRA-3300
URL: https://issues.apache.org/jira/browse/CASSANDRA-3300
Project: Cassandra
Issue Type: Task
Components: Drivers
Reporter: Eric Evans
Priority: Minor
Labels: cql
Attachments: v1-0001-CASSANDRA-3300-remove-driver-build-test.txt

A new project as been created at
http://code.google.com/a/apache-extras.org/p/cassandra-jdbc, a current
snapshot of the code from trunk has been imported, and the tests updated.
I've configured commit notifications to be sent to
commits@cassandra.apache.org, though this can be changed if people object.
To the best of my knowledge, the only thing remaining is to configure the
initial set of committers and admins.

[jira] [Commented] (CASSANDRA-3300) relocate Java (JDBC) CQL driver

2011-10-13 Thread Eric Evans (Commented) (JIRA)

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

Eric Evans commented on CASSANDRA-3300:
---

bq. Using cassandra-maven-plugin to start a cassandra server for running the
integration tests.

The idea is that at some point, there will be an established set of tests that
each driver must implement. An automated system will then run each driver's
test suite against the current, and some number of older versions of Cassandra.
All of this will be used as a sort of acceptance criteria for
blessing/certifying/whatever.

Currently, having the tests connect to an already running Cassandra instance
seems like the best way to make that work consistently against an arbitrary
number of drivers (i.e. let the test system spin-up different versions of
Cassandra prior to each test run).

TL;DR
Unless you have alternatives to the above, please make sure to support a simple
test mode that connects to Cassandra on a configurable host and port.

relocate Java (JDBC) CQL driver
---

[jira] [Commented] (CASSANDRA-3300) relocate Java (JDBC) CQL driver

2011-10-10 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3300:
---

Sorry for the delay on this; I'll followup with a patch that removes the 
necessary bits from build.xml shortly

 relocate Java (JDBC) CQL driver
 ---

 Key: CASSANDRA-3300
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3300
 Project: Cassandra
  Issue Type: Task
  Components: Drivers
Reporter: Eric Evans
Priority: Minor
  Labels: cql

 A new project as been created at 
 http://code.google.com/a/apache-extras.org/p/cassandra-jdbc, a current 
 snapshot of the code from trunk has been imported, and the tests updated.
 I've configured commit notifications to be sent to 
 commits@cassandra.apache.org, though this can be changed if people object.
 To the best of my knowledge, the only thing remaining is to configure the 
 initial set of committers and admins.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3299) clientutil depends on FBUtilities (bad)

2011-10-10 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3299:
---

you're right; my bad, committed to cassandra-1.0 as well

 clientutil depends on FBUtilities (bad)
 ---

 Key: CASSANDRA-3299
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3299
 Project: Cassandra
  Issue Type: Bug
  Components: API, Drivers
Affects Versions: 1.0.0
Reporter: Eric Evans
Assignee: Eric Evans
  Labels: cql
 Fix For: 1.0.1

 Attachments: 
 v1-0001-CASSANDRA-3299-move-FBUtils-methods-for-bytes-hex-to-s.txt


 clientutils' (indirect )dependency on FBUtilities (needed for tests) would 
 result in huge numbers of classes being pulled in transitively.
 The attached patch moves the {{bytesToHex}} and {{hexToBytes}} methods into a 
 new class ({{o.a.c.utils.Hex}}), which has no external dependencies.
 This should be pretty safe, but I've marked it fixfor-1.0.1 since we're so 
 close to release, and because the JDBC driver can embed a snapshot jar in the 
 meantime.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3300) relocate Java (JDBC) CQL driver

2011-10-10 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3300:
---

The attached patch, combined with an `svn rm drivers/' should be enough to call 
this a Done Deal.

 relocate Java (JDBC) CQL driver
 ---

 Key: CASSANDRA-3300
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3300
 Project: Cassandra
  Issue Type: Task
  Components: Drivers
Reporter: Eric Evans
Priority: Minor
  Labels: cql
 Attachments: v1-0001-CASSANDRA-3300-remove-driver-build-test.txt


 A new project as been created at 
 http://code.google.com/a/apache-extras.org/p/cassandra-jdbc, a current 
 snapshot of the code from trunk has been imported, and the tests updated.
 I've configured commit notifications to be sent to 
 commits@cassandra.apache.org, though this can be changed if people object.
 To the best of my knowledge, the only thing remaining is to configure the 
 initial set of committers and admins.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3299) clientutil depends on FBUtilities (bad)

2011-10-03 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3299:
---

I'm OK with that, but are those names going to be too generic if someone 
decides to do a static import?

 clientutil depends on FBUtilities (bad)
 ---

 Key: CASSANDRA-3299
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3299
 Project: Cassandra
  Issue Type: Bug
  Components: API, Drivers
Affects Versions: 1.0.0
Reporter: Eric Evans
Assignee: Eric Evans
  Labels: cql
 Fix For: 1.0.1

 Attachments: 
 v1-0001-CASSANDRA-3299-move-FBUtils-methods-for-bytes-hex-to-s.txt


 clientutils' (indirect )dependency on FBUtilities (needed for tests) would 
 result in huge numbers of classes being pulled in transitively.
 The attached patch moves the {{bytesToHex}} and {{hexToBytes}} methods into a 
 new class ({{o.a.c.utils.Hex}}), which has no external dependencies.
 This should be pretty safe, but I've marked it fixfor-1.0.1 since we're so 
 close to release, and because the JDBC driver can embed a snapshot jar in the 
 meantime.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CASSANDRA-3239) can't use RackInferringSnitch and CQL JDBC's CREATE KEYSPACE with NetworkTopologyStrategy

2011-09-27 Thread Eric Evans (Commented) (JIRA)


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

Eric Evans commented on CASSANDRA-3239:
---

+1

 can't use RackInferringSnitch and CQL JDBC's CREATE KEYSPACE with 
 NetworkTopologyStrategy
 ---

 Key: CASSANDRA-3239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-3239
 Project: Cassandra
  Issue Type: Bug
  Components: API
Affects Versions: 0.8.0
Reporter: M Chen
Assignee: Pavel Yaskevich
Priority: Minor
 Fix For: 0.8.7

 Attachments: CASSANDRA-3239.patch


 If using the CQL JDBC driver, there's a problem with using RackInferringSnitch
 1. With RackInferringSnitch, the datacenter names are numeric
 2. With CQL and NetworkTopologyStrategy, the data center replicas are 
 specified as strategy_options:dc-name=#-of-replicas
 3. Using a number for dc-name fails
 4. Using a quoted number for dc-name fails

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

91 matches

Mail list logo