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, '');
InvalidRe
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
3
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 -cassandra
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,
etc
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 because no one is working
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 =
I suppose given the short lifetime of each Java release you could argue
we're always close to EOL. I feel like we shouldn't ship with a version
that is currently EOL.
Coming up with a policy for all upcoming releases may also be incredibly
difficult. 6 months java releases could pan out like Tic
> 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 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.
Personally I'd prefer not to tie our releases to any vendor / product /
package's release schedule.
On Fri, Mar 23,
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 base
>
> 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 Michael is right. It w
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 lo
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
13 matches
Mail list logo