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 > > > > >