New features don't necessarily restrict bugs only to those features. (only
in our dreams). Often features may touch on parts of the code that could
cause issues for other parts of the system.
To clarify, just because you don't use new features, doesn't mean you are
free from the risk of their bugs.
On 14 October 2016 at 00:23, Jonathan Haddad <j...@jonhaddad.com> wrote:
> If you're not using the features why use a release that nobody else (read:
> experienced users) is?
>
> What do you need in 3.x that's not available in 3.0?
>
> On Thu, Oct 13, 2016 at 5:23 PM Eric Ho <e...@analyticsmd.com> wrote:
>
>> But if I'm not doing anything fancy w/ C* (i.e. don't use new features in
>> 3.{2,4,6}) then I'll be fine, right ?
>>
>>
>> -eric ho
>>
>>
>> On Thu, Oct 13, 2016 at 5:09 PM, Jonathan Haddad <j...@jonhaddad.com>
>> wrote:
>>
>> I listed my reasons, please check my previous email.
>>
>> On Thu, Oct 13, 2016 at 4:55 PM Eric Ho <e...@analyticsmd.com> wrote:
>>
>> Why 3.0.x ? Why not use 3.2.x or 3.4.x ? or 3.6.x ?
>> Shouldn't 3.6.x be more stable than say 3.2.x ?
>>
>>
>> -eric ho
>>
>>
>> On Thu, Oct 13, 2016 at 3:48 PM, Jonathan Haddad <j...@jonhaddad.com>
>> wrote:
>>
>> Here's your basic options:
>>
>> 1. Triggers (avoid like the plague)
>> 2. CDC (really new, tricky to avoid RF operations as is, probably avoid)
>> 3. Do it in your app
>> 4. Put Kafka in front of your data, write as many consumers as you want
>> to write the data in as many ways as you want
>>
>> Also, how long have you been using Cassandra? Unless you're comfortable
>> rolling your own builds and merging in bugfixes from upstream, I really
>> suggest using a 3.0.x release instead of a 3.7.
>>
>> 3.7 falls under the Tick Tock release cycle, which is almost completely
>> untested in production by experienced operators. In the cases where it
>> has
>> been tested, there have been numerous bugs found which I (and I think most
>> people on this list) consider to be show stoppers. Additionally, the Tick
>> Tock release cycle puts the operator in the uncomfortable position of
>> having to decide between upgrading to a new version with new features
>> (probably new bugs) or back porting bug fixes from future versions
>> themselves. There will never be a 3.7.1 release which fixes bugs in 3.7
>> without adding new features.
>>
>> https://github.com/apache/cassandra/blob/trunk/NEWS.txt
>>
>> For new projects I recommend starting with the recently released 3.0.9.
>>
>> Assuming the project changes it's policy on releases (all signs point to
>> yes), then by the time 4.0 rolls out a lot of the features which have been
>> released in the 3.x series will have matured a bit, so it's very possible
>> 4.0 will stabilize faster than the usual 6 months it takes for a major
>> release.
>>
>> All that said, there's nothing wrong with doing compatibility & smoke
>> tests
>> against the latest 3.x release as well as 3.0 and reporting bugs back to
>> the Apache Cassandra JIRA, I'm sure it would be greatly appreciated.
>>
>> https://issues.apache.org/jira/secure/Dashboard.jspa
>>
>> Jon
>>
>>
>>
>> On Thu, Oct 13, 2016 at 3:15 PM Eric Ho <e...@analyticsmd.com> wrote:
>>
>> Some suggested Elassandra. But that is based on Cassandra 2.2.
>> I would like to use Cassandra 3.7 and up...
>>
>>
>>
>> -eric ho
>>
>>
>> On Thu, Oct 13, 2016 at 3:04 PM, vincent gromakowski <
>> vincent.gromakow...@gmail.com> wrote:
>>
>> Elassandra
>> https://github.com/vroyer/elassandra
>>
>> Le 14 oct. 2016 12:02 AM, "Eric Ho" <e...@analyticsmd.com> a écrit :
>>
>> I don't want to change my code to write into C* and then to ES.
>> So, I'm looking for some sort of a sync tool that will sync my C* table
>> into ES and it should be smart enough to avoid duplicates or gaps.
>> Is there such a tool / plugin ?
>> I'm using stock apache Cassandra 3.7.
>> I know that some premium Cassandra has ES builtin or integrated but I
>> can't afford premium right now...
>> Thanks.
>>
>> -eric ho
>>
>>
>>
>>
>>
--
Kurt Greaves
k...@instaclustr.com
www.instaclustr.com
