[jira] [Commented] (CASSANDRA-3990) cqlsh support for CQL 3
[ https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248448#comment-13248448 ] Eric Evans commented on CASSANDRA-3990: --- >From IRC: {noformat} 11:59 < urandom> pcmanus: when you get a sec, let me know whether you think #3990 should be merged to 1.1.0 11:59 < CassBotJr> https://issues.apache.org/jira/browse/CASSANDRA-3990 : cqlsh support for CQL 3 12:00 < pcmanus> urandom: I'm fine with it (as part of our CQL3 is beta and excluded of freeze) {noformat} So, added to cassandra-1.1.0 as well. > 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-3990) cqlsh support for CQL 3
[ https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3990) cqlsh support for CQL 3
[ https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3991) Investigate importance of jsvc in debian packages
[ https://issues.apache.org/jira/browse/CASSANDRA-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/CASSANDRA-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3778) KEY IN (...) queries do not work
[ https://issues.apache.org/jira/browse/CASSANDRA-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3665) [patch] allow for clientutil.jar to be used without the base cassandra.jar for client applications
[ https://issues.apache.org/jira/browse/CASSANDRA-3665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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). -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 '' 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 PRIMARY KEY, column , value ) 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 behaves now. Or m
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > > > 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-2478) Custom CQL protocol/transport
[ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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} +1 > Custom CQL protocol/transport > - > > Key: CASSANDRA-2478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2478 > Project: Cassandra > Issue Type: New Feature > Components: API, Core >Reporter: Eric Evans >Priority: Minor > Labels: cql > > A custom wire protocol would give us the flexibility to optimize for our > specific use-cases, and eliminate a troublesome dependency (I'm referring to > Thrift, but none of the others would be significantly better). Additionally, > RPC is bad fit here, and we'd do better to move in the direction of something > that natively supports streaming. > I don't think this is as daunting as it might seem initially. Utilizing an > existing server framework like Netty, combined with some copy-and-paste of > bits from other FLOSS projects would probably get us 80% of the way there. -- This message is automatically generated by JIRA. 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > > > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > > > 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: Pavel Yaskevich > 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-3507) Proposal: separate cqlsh from CQL drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3633) update stress to support prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175735#comment-13175735 ] Eric Evans commented on CASSANDRA-3634: --- OK, just for posterity sake, here are the results from that 50 column insert test. It's less than the 10% I mentioned, but I'm not sure I trust that since the BB-based test seems to taper off toward the end for reasons unknown. BB is +9.4% throughput at the half-way point. !http://people.apache.org/~eevans/3634/insert_20mx50_noidx_t50_20111223.png|width=700! || ||Average OP rate||Average Latency|| |CQL w/ Prepared statements|7,137/s|5.7ms| |CQL w/ Prepared statements (binary parms)|7,257/s|5.7ms| > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3634) compare string vs. binary prepared statement parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3397) Problem markers don't show up in Eclipse
[ https://issues.apache.org/jira/browse/CASSANDRA-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3458) Add cqlsh to deb and rpm packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3458) Add cqlsh to deb and rpm packaging
[ https://issues.apache.org/jira/browse/CASSANDRA-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3424) Selecting just the row_key returns nil instead of just the row_key
[ https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3424) Selecting just the row_key returns nil instead of just the row_key
[ https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3649) Code style changes, aka The Big Reformat
[ https://issues.apache.org/jira/browse/CASSANDRA-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169908#comment-13169908 ] Eric Evans commented on CASSANDRA-2475: --- bq. Me, too. Feels like premature defensiveness to me. I think we're a lot more likely to have someone get bitten from PS number 51 failing, than from OOMing because of 100,000 if we just say "we'll keep them around until you close them or disconnect." To clarify, you're saying you're in favor of putting no constraints whatsoever on the number of stored statements, and relying solely on clients to free them up? Does this change at all (the perceived likelihood) if the number were 1,000 instead of 51? Or 10,000? And, to be clear about what I was thinking: Short of a (seriously )buggy client, my expectation is that there would be no reason we couldn't hold as many of these statements as needed (with or without an API to remove them on close()). Based on that assumption, the LRU map was a brake against buggy clients (and so should probably be much higher than 50), and the API to remove them was unnecessary. > 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > > -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. OK {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 > --- > > 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-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3570) barrier-of-entry: make ./bin/cassandra -f work out of the box by changing default cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164403#comment-13164403 ] Eric Evans commented on CASSANDRA-3570: --- bq. As the only? committer not using a Unix-based primary workstation, I suppose it falls to me to point out that /var/* is not a cross-platform standard either. Yeah, fair enough. Though if this is something that falls into the category of cant-be-guessed-so-recommend, then an FHS-based recommendation is still the clear choice. Maybe there should be some entries adjacent to these, commented out, which include the corresponding recommended Windows paths. Also, I just had one other thought. Paths in {{cassandra.yaml}} are all expected to be absolute. The startup scripts are smart enough to work with relative paths when called from elsewhere, but a relative path of db/ placed in {{cassandra.yaml}} will fail unless $PWD at startup is the top-level directory. I know this is meant to optimize for that case, but that's still kind of dodgy. > 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. -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162433#comment-13162433 ] Eric Evans commented on CASSANDRA-3570: --- {quote} It's that too. And even with proper distributed testing across real clusters, it's still useful to be able to switch around between different versions and just start Cassandra. Not all testing, particularly when iterating something, is best done by Super Proper Distributed Test Setup. In this particular case all I wanted to do was to start Cassandra and test with the latest version of G1 (looking for very specific behavior), and there is no reason to do the thing I wanted to do in any any less ad-hoc fashion. I have no trouble admitting that I some times want to run Cassandra out of my working copy; it is not indicative of bad testing practices because the two are not mutually exclusive. And it's not just about testing; I have had plenty of cases where I have been tracking down bugs by repeatedly re-starting a single node-local Cassandra and watching for debug printouts. There's no reason to make that more complicated by running said Super Proper Distributed Test Setup. {quote} Are you aware that (on trunk at least) you can simple run {{ant test-run}} from a source tree? bq. And note that this JIRA isn't just about that paragraph you quoted. Sorry, I quoted all of it this time. :) bq. Basically, is anyone helped by the default config being non-usable for non-root? If not, it seems like a small thing that is just annoying in certain situation that might as well just be changed. And I won't have to hymn and haw when I can't quite tell someone "Just clone it, typ ant, and run ./bin/cassandra -f". A default is just that, default. There is no possible way to use settings that will work for everyone, all of the time (if there were, we wouldn't need a config). The aim is to use what will work for most, most of the time, and to document recommendations for the rest. The /var/{lib,log}/cassandra paths are the recommendation we've been making to users for production environments. I'm not saying, "you are wrong, it should be left as-is", I'm asking, "does {{./db}} better serve a majority of users the majority of time?" You and I are naturally biased toward the use-case of ad hoc testing (FWIW, I added the {{test-run}} target specifically for this reason), so I believe that's a fair question to pose. > 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. -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162260#comment-13162260 ] Eric Evans commented on CASSANDRA-2475: --- Rick, is this meant to be applied to trunk? I think it needs to be rebased. > 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 > > -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3527) Expose JMX values via CQL interface
[ https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3498) Add same-row contention mode to stress tool
[ https://issues.apache.org/jira/browse/CASSANDRA-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 [ | | 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 [ | | 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139068#comment-13139068 ] Eric Evans commented on CASSANDRA-3420: --- v2 also includes a description that might help drive home the point for some. > 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, > v2-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-3420) test run from ant
[ https://issues.apache.org/jira/browse/CASSANDRA-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3188) cqlsh 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 [ | | 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-3397) Problem markers don't show up in Eclipse
[ https://issues.apache.org/jira/browse/CASSANDRA-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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 -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131280#comment-13131280 ] Eric Evans commented on CASSANDRA-3380: --- {quote} If I were going to do it, I'd do it the way CQL does, which is to use the to/fromString methods to attempt to parse the json string as what the schema says it should be. {quote} Right, my point was that once you've built out the client code to introspect Cassandra's schema and marshal to string and back again, the curl examples stop looking so straightforward, and "understanding http + json" isn't good enough anymore. > 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 -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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 -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13130996#comment-13130996 ] Eric Evans commented on CASSANDRA-3380: --- I have no doubt that a REST interface is useful to some, but the question is, does it belong integrated directly into Cassandra? I don't have any hard numbers, but requests for a REST interface have been intermittent, and come from what I perceive to be a small minority. I've also mentioned elsewhere that I believe some of these people were asking for REST, but were really looking for simpler client abstractions (which CQL now provides). What is certain is that most Cassandra users are very interested in performance, and make use of Cassandra's rich types, both of which are sacrificed for this REST interface. Again, that doesn't invalidate your approach, but it suggests to me that it isn't broadly applicable. Another factor when asking if this should be integrated is how feasible it would be to maintain this outside of Cassandra. I could be missing something, but it seems like it would be quite easy. > 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 -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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 -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > --- > > 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-3300) relocate Java (JDBC) CQL driver
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/CASSANDRA-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/CASSANDRA-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CASSANDRA-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:=<#-of-replicas> > 3. Using a number for fails > 4. Using a quoted number for 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