Re: Inserting list data

Sorry this is so long after the initial. I wrote a dtest to try to make this happen here: https://github.com/bakerag1/cassandra-dtest/blob/master/collection_update_test.py This is my first dtest and my second python script, so I am not overly confident that it is doing a good job of this test, so

Save the date: ApacheCon Miami, May 15-19, 2017

Dear Apache enthusiast, ApacheCon and Apache Big Data will be held at the Intercontinental in Miami, Florida, May 16-18, 2017. Submit your talks, and register, at http://apachecon.com/ Talks aimed at the Big Data section of the event should go to

Re: Which version is stable enough for production environment?

Thanks. I left some comments. LeveledCompaction: Have you checked if there where major changes in the LeveledStrategy between 2.x and 3.x? 2016-11-30 21:04 GMT+01:00 Harikrishnan Pillai : > https://issues.apache.org/jira/browse/CASSANDRA-12728 > > [CASSANDRA-12728]

Sanity checks to run post restore data?

Hi, We are periodically backing up sstables, and need to learn, what sanity checks should be performed after restoring them? Thanks, Varun

Re: Why does `now()` produce different times within the same query?

Sorry for my typo. Obviously, I meant: "It appears that a single query that calls Cassandra's`now()` time function *multiple times *may actually cause a query to write or return different times." Less of a surprise now that I realize more about the implementation, but I agree that more explicit

Re: Which version is stable enough for production environment?

https://issues.apache.org/jira/browse/CASSANDRA-12728 [CASSANDRA-12728] Handling partially written hint files ... issues.apache.org Cassandra; CASSANDRA-12728; Handling partially written hint files. Agile Board; Awaiting Feedback; Export

Re: Which version is stable enough for production environment?

I didn't mean to criticise you. It was meant as a notice for all of those who are planning to use MVs. I already made proposals to solve these issues on the dev list and plan to test them on our own cluster during the next days. I am currently working heavily on this as we have big trouble

Re: Which version is stable enough for production environment?

Yes Benjamin, no one said it wouldn't. We're actively backporting things as we get time, if you find something you'd like backported raise an issue and let us know. We're well aware of the issues affecting MVs, but they haven't really been solved anywhere yet. On 30 November 2016 at 07:54,

Re: Which version is stable enough for production environment?

Like I said, test in a lower environment first with your data model to be sure. *Brooke Jensen* VP Technical Operations & Customer Services www.instaclustr.com | support.instaclustr.com This email has been sent on behalf of Instaclustr Limited

Cassandra 2.x Stability

Hi Everyone, I'm about to upgrade our 2.0.14 version to a newer 2.x version. At first I thought of upgrading to 2.2.8, but I'm not sure how stable it is, as I understand the 2.2 version was supposed to be a sort of beta version for 3.0 feature-wise, whereas 3.0 upgrade will mainly handle the

Re: Cassandra 2.x Stability

Latest release in 2.2. 2.1 is borderline EOL and from my experience 2.2 is quite stable and has some handy bugfixes that didn't actually make it into 2.1 On 30 November 2016 at 10:41, Shalom Sagges wrote: > Hi Everyone, > > I'm about to upgrade our 2.0.14 version to a

Re: Cassandra 2.x Stability

You should also consider end of support term, as Cassandra page says: Apache Cassandra 2.2 is supported until November 2016. Apache Cassandra 2.1 is supported until November 2016 with critical fixes only So 2.1 actually don't get any fixes, even critical. Best regards, Vladimir Yudovin,

Re: Why does `now()` produce different times within the same query?

This is not a bug, and in fact changing it would be a serious bug. False. Absolutely no consumer would be broken by a change to guarantee an identical time component that isn't broken already, for the simple reason your code already has to handle that case, as it is in fact the majority case

Re: Why does `now()` produce different times within the same query?

tl;dr +1 yup raise a jira to discuss how now() should behave in a single statement (and possible extend to batch statements). The values of now should be the same if you assume that now() works like it does in relational databases such as postgres or mysql, however at the moment it instead works

Re: Why does `now()` produce different times within the same query?

Getting the same TimeUUID values might be a major problem. Getting two different TimeUUIDs that at least have time component would not be a major problem as this is the main case today. Getting different time components is actually the corner case, and it is a corner case that breaks

full repair or incremental repair after scrub?

Hi, do I have to do a full repair after scrub? Is it enough to just do incremental repair? BTW I do nightly incremental repair.

Re: Why does `now()` produce different times within the same query?

FWIW I'd suggest opening a bug--this behavior is certainly quite unexpected and more than just a documentation issue. In general I can't imagine any desirable properties of the current implementation, and there are likely a bunch of latent bugs sitting out there, so it should be fixed. Todd On

Re: Why does `now()` produce different times within the same query?

In my opinion, this is not broken and “fixing” it would break existing code. Consider a batch that includes multiple inserts, each of which inserts the value returned by now(). Getting the same UUID for each insert would be a major problem. Cheers Robert On Nov 30, 2016, at 4:46 PM, Todd

Re: Why does `now()` produce different times within the same query?

Great comment. +1 Am 01.12.2016 06:29 schrieb "Ben Bromhead" : > tl;dr +1 yup raise a jira to discuss how now() should behave in a single > statement (and possible extend to batch statements). > > The values of now should be the same if you assume that now() works like > it

Re: Why does `now()` produce different times within the same query?

This is not a bug, and in fact changing it would be a serious bug. What it is is a wonderful case of bad coding: would one expect a java/py/bash script that loops on a bunch of read/execut/update calls where each iteration calls time to return the same exact time for the duration of the execution

Re: Why does `now()` produce different times within the same query?

On Wed, Nov 30, 2016 at 10:53 PM, Cody Yancey wrote: > This is not a bug, and in fact changing it would be a serious bug. > > False. Absolutely no consumer would be broken by a change to guarantee an > identical time component that isn't broken already, for the simple reason