Empty partition keys allowed in MV, but not in normal table

Hi, Given the following table: cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1}; cqlsh> create table t (p text, c int, v text, primary key (p)); cqlsh> use ks; The following fails: cqlsh:ks> insert into t (p, c, v) values ('', 2, '');

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

On Fri, 23 Mar 2018 15:52:51 +, you wrote: >Java 8 was marked as EOL in the middle of last year, I hope we wouldn't >require it for Cassandra 4. At this point I feel like we should already be >targeting Java 10 at a minimum. Given that the last messages indicated aiming Cassandra 4 for the

question on running cassandra-dtests

Hi All, I am trying to setup and run Cassandra-dtests so that I can write some tests for a JIRA ticket I have been working on. This is the repo I am using: https://github.com/apache/cassandra-dtest I followed all the instructions and installed dependencies. However, when I run "pytest

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

I am now thinking that aligning to the major JDK release that is for-pay three years if you want it is the best strategy. What I think will happen is that there will be a consortium that maintains/backports that release level independent of oracle, if only to spite them. I'm thinking IBM, Azul,

Re: IN restrictions are not supported on indexed columns

There are not real blocker I believe. It is just that we never implemented it. On Fri, Mar 23, 2018 at 6:08 PM, Dikang Gu wrote: > Hello C* developers: > > I have one question, does anyone know why we can not support the IN > restrictions on indexed columns? Is it just

IN restrictions are not supported on indexed columns

Hello C* developers: I have one question, does anyone know why we can not support the IN restrictions on indexed columns? Is it just because no one is working it? Or are there any other reasons? Below is an example query: cqlsh:ks1> describe keyspace; CREATE KEYSPACE ks1 WITH replication

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

> At this point I feel like we should already be > targeting Java 10 at a minimum. Barring some surprises from other people supporting 10 longer-term, wouldn't that be coupling C*'s 4.0 release with a runtime that's likely EOL shortly after? On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Java 8 was marked as EOL in the middle of last year, I hope we wouldn't require it for Cassandra 4. At this point I feel like we should already be targeting Java 10 at a minimum. Personally I'd prefer not to tie our releases to any vendor / product / package's release schedule. On Fri, Mar 23,

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

I'm coming to be on-board with #3. One thing to watch out for (we can't account for it now) is how our dependencies choose to move forward. If we need to upgrade a jar (netty, for example) due to some leak or vulnerability, and it only runs on a higher version, we may be forced to upgrade the

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

> > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later This seems like the best of our bad options, with the addition of "optionally". On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen wrote: > On Fri, 23 Mar 2018 04:54:23 +, you wrote: > > >I think

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

On Fri, 23 Mar 2018 04:54:23 +, you wrote: >I think Michael is right. It would be impossible to make everyone follow >such a fast release scheme, and supporting it will be pressured onto the >various distributions, M$ and Apple. >On the other hand https://adoptopenjdk.net has already done a

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

I think it's pretty safe to assume that Java 8 will stay around much longer than by the end of the year, after Oracle dropped their official maintainer role. I also think that we don't have to worry that much how exactly Java 8 is going to be supported. It's a mature enough version that I wouldn't