Re: Criteria for upgrading to 3.x releases in PROD

[Jonathan Ellis]

Anuj,

The problem is that this question defies a simplistic answer like "version
X is the most stable" (are you willing to use unsupported releases?  what
about emergency-fix-only?  what features can you not live without?) so
we're intentionally resisting the urge to oversimplify the situation.

On Mon, Apr 18, 2016 at 8:25 PM, Anuj Wadehra <
anujw_2...@yahoo.co.in.invalid> wrote:

> Hi All,
> Let me reiterate, my question is not about selecting right Cassandra for
> me. The intent is to get dev community response on below question.
> Question:
> Would it be a wise decision to mention the "most stable/production
> ready" version (as it used to be before 3.x) on the Apache website till
> tick-tock release strategy evolves and matures?
>
> Drivers for posting above info on website:
>  I have read all the posts/forums and realized that there is no absolute
> answer for selecting Production Ready Cassandra version one should
> use..Even now, people often hesitate to recommend latest releases for Prod
> and go back to 2.1 and 2.2..In every suggestion there are too many
> ifs..like I said...if you want features x..if u want rock solid y..if you
> are adventurous zno offense but  who would not want a rock solid
> version for Production? Who would want features for stability in Prod? And
> who would want to take risks in Prod?
>  The stability of a release should NOT depend my risk appetite and use
> case..if some version of 2.1 or 2.2 or 3.0.x is stable for production why
> not put that info until tick-tock matures?
>
> Please realize that everyone goes for thorough testing before upgrading
> but the scope of application testing cant uncover most critical
> bugs..Community guidance and a bigger picture on stability can help the
> community until tick-tock matures and we deliver stable production ready
> releases.
>
>
>
> ThanksAnuj
> Sent from Yahoo Mail on Android
>
>   On Tue, 19 Apr, 2016 at 3:01 AM, Carlos Rolo wrote:
>  My blog post regarding this:
>
> https://www.pythian.com/blog/cassandra-version-production/
>
> There is a choice for everyone, and explained.
>
> Regards,
>
> Carlos Juzarte Rolo
> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP
>
> Pythian - Love your data
>
> rolo@pythian | Twitter: @cjrolo | Linkedin: *
> linkedin.com/in/carlosjuzarterolo
> *
> Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
> www.pythian.com
>
> On Mon, Apr 18, 2016 at 7:12 PM, Anuj Wadehra <
> anujw_2...@yahoo.co.in.invalid> wrote:
>
> > I am sorry but here, I am not expecting thousands to decide a stable
> > version for my use case. I have a serious question about publishing some
> > info on the Apache website. As dev list has active contributors, I posted
> > it here. If not this forum, Whats the best way to put your suggestions
> > regarding Apache content and initiate a meaningful and conclusive
> > discussion thread?
> >
> > ThanksAnuj
> >
> > Sent from Yahoo Mail on Android
> >
> >  On Mon, 18 Apr, 2016 at 11:27 PM, Michael Kjellman<
> > mkjell...@internalcircle.com> wrote:  This is best for the users list.
> > Test the releases yourself and then decide when it's ready for your use
> > case, ops team, and organization. This is a personal decision and not one
> > for *thousands* of others on this mailing list to make for you.
> >
> > best,
> > kjellman
> >
> > > On Apr 18, 2016, at 10:54 AM, Anuj Wadehra
> >  wrote:
> > >
> > > Hi All,
> > > For last several months, the "most stable version" question pops up on
> > the user mailing list and then people get all sorts of
> > responses/suggestions..
> > > If you are conservative go for x if adventurous y..
> > > If you have good risk appetite go for x else y..
> > > If you want features go for x else y..
> > >
> > > Unfortunately, all above responses dont help many users..but only
> > reinforce the low confidence in latest releases.Who wants to be
> adventurous
> > in Production? Who wants to test his risk appetite in Production? And who
> > would want features for stability in Production? Not many..I am sure.
> > > So my question is:
> > > Would it be a wise decision to mention the "most stable/production
> > ready" version (as it used to be before 3.x) on the Apache website till
> > tick-tock release strategy evolves and matures?
> > >  That will somewhat contradict the tick-tock philosphy of stable odd
> > releases but would be more realistic as every big change needs time to
> > stabilise. Its slightly unfair, if users are kept in confused state till
> > the strategy matures and starts delivering solid stable builds.
> > > I think the question is more appropriate in dev list so I have kept it
> > here.
> > > ThanksAnuj
> > > Sent from Yahoo Mail on Android
> > >
> > >  On Mon, 11 Apr, 2016 at 11:39 PM, Aleksey Yeschenko<
> alek...@apache.org>
> > wrote:  The answer will depend on how conservative you are.
> > >
> > > The most conservative 

Re: Criteria for upgrading to 3.x releases in PROD

[Anuj Wadehra]

Hi All,
Let me reiterate, my question is not about selecting right Cassandra for me. 
The intent is to get dev community response on below question.
Question:
Would it be a wise decision to mention the "most stable/production
ready" version (as it used to be before 3.x) on the Apache website till
tick-tock release strategy evolves and matures?

Drivers for posting above info on website:
 I have read all the posts/forums and realized that there is no absolute answer 
for selecting Production Ready Cassandra version one should use..Even now, 
people often hesitate to recommend latest releases for Prod and go back to 2.1 
and 2.2..In every suggestion there are too many ifs..like I said...if you want 
features x..if u want rock solid y..if you are adventurous zno offense but  
who would not want a rock solid version for Production? Who would want features 
for stability in Prod? And who would want to take risks in Prod? 
 The stability of a release should NOT depend my risk appetite and use case..if 
some version of 2.1 or 2.2 or 3.0.x is stable for production why not put that 
info until tick-tock matures? 

Please realize that everyone goes for thorough testing before upgrading but the 
scope of application testing cant uncover most critical bugs..Community 
guidance and a bigger picture on stability can help the community until 
tick-tock matures and we deliver stable production ready releases.



ThanksAnuj
Sent from Yahoo Mail on Android 
 
  On Tue, 19 Apr, 2016 at 3:01 AM, Carlos Rolo wrote:   My 
blog post regarding this:

https://www.pythian.com/blog/cassandra-version-production/

There is a choice for everyone, and explained.

Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
www.pythian.com

On Mon, Apr 18, 2016 at 7:12 PM, Anuj Wadehra <
anujw_2...@yahoo.co.in.invalid> wrote:

> I am sorry but here, I am not expecting thousands to decide a stable
> version for my use case. I have a serious question about publishing some
> info on the Apache website. As dev list has active contributors, I posted
> it here. If not this forum, Whats the best way to put your suggestions
> regarding Apache content and initiate a meaningful and conclusive
> discussion thread?
>
> ThanksAnuj
>
> Sent from Yahoo Mail on Android
>
>  On Mon, 18 Apr, 2016 at 11:27 PM, Michael Kjellman<
> mkjell...@internalcircle.com> wrote:  This is best for the users list.
> Test the releases yourself and then decide when it's ready for your use
> case, ops team, and organization. This is a personal decision and not one
> for *thousands* of others on this mailing list to make for you.
>
> best,
> kjellman
>
> > On Apr 18, 2016, at 10:54 AM, Anuj Wadehra
>  wrote:
> >
> > Hi All,
> > For last several months, the "most stable version" question pops up on
> the user mailing list and then people get all sorts of
> responses/suggestions..
> > If you are conservative go for x if adventurous y..
> > If you have good risk appetite go for x else y..
> > If you want features go for x else y..
> >
> > Unfortunately, all above responses dont help many users..but only
> reinforce the low confidence in latest releases.Who wants to be adventurous
> in Production? Who wants to test his risk appetite in Production? And who
> would want features for stability in Production? Not many..I am sure.
> > So my question is:
> > Would it be a wise decision to mention the "most stable/production
> ready" version (as it used to be before 3.x) on the Apache website till
> tick-tock release strategy evolves and matures?
> >  That will somewhat contradict the tick-tock philosphy of stable odd
> releases but would be more realistic as every big change needs time to
> stabilise. Its slightly unfair, if users are kept in confused state till
> the strategy matures and starts delivering solid stable builds.
> > I think the question is more appropriate in dev list so I have kept it
> here.
> > ThanksAnuj
> > Sent from Yahoo Mail on Android
> >
> >  On Mon, 11 Apr, 2016 at 11:39 PM, Aleksey Yeschenko
> wrote:  The answer will depend on how conservative you are.
> >
> > The most conservative choice overall would be to go with the 2.2.x line.
> >
> > 3.0.x if you want to the new nice and shiny 3.0 things, but can tolerate
> some risk (the branch has a lot of relatively new core code, and hasn’t yet
> been tried out by as many users as the 2.x branch had).
> >
> > The latest odd 3.x if you want the shiniest (3.5 to be released soon,
> with features like the new SASI secondary indexes support). Also, there
> hasn’t yet been that much divergence between 3.0.x and 3.x, so risk levels
> are around the same, so long as you limit yourself to only the features
> 

Re: Criteria for upgrading to 3.x releases in PROD

[Carlos Rolo]

My blog post regarding this:

https://www.pythian.com/blog/cassandra-version-production/

There is a choice for everyone, and explained.

Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 91 891 81 00 | Tel: +1 613 565 8696 x1649
www.pythian.com

On Mon, Apr 18, 2016 at 7:12 PM, Anuj Wadehra <
anujw_2...@yahoo.co.in.invalid> wrote:

> I am sorry but here, I am not expecting thousands to decide a stable
> version for my use case. I have a serious question about publishing some
> info on the Apache website. As dev list has active contributors, I posted
> it here. If not this forum, Whats the best way to put your suggestions
> regarding Apache content and initiate a meaningful and conclusive
> discussion thread?
>
> ThanksAnuj
>
> Sent from Yahoo Mail on Android
>
>   On Mon, 18 Apr, 2016 at 11:27 PM, Michael Kjellman<
> mkjell...@internalcircle.com> wrote:   This is best for the users list.
> Test the releases yourself and then decide when it's ready for your use
> case, ops team, and organization. This is a personal decision and not one
> for *thousands* of others on this mailing list to make for you.
>
> best,
> kjellman
>
> > On Apr 18, 2016, at 10:54 AM, Anuj Wadehra
>  wrote:
> >
> > Hi All,
> > For last several months, the "most stable version" question pops up on
> the user mailing list and then people get all sorts of
> responses/suggestions..
> > If you are conservative go for x if adventurous y..
> > If you have good risk appetite go for x else y..
> > If you want features go for x else y..
> >
> > Unfortunately, all above responses dont help many users..but only
> reinforce the low confidence in latest releases.Who wants to be adventurous
> in Production? Who wants to test his risk appetite in Production? And who
> would want features for stability in Production? Not many..I am sure.
> > So my question is:
> > Would it be a wise decision to mention the "most stable/production
> ready" version (as it used to be before 3.x) on the Apache website till
> tick-tock release strategy evolves and matures?
> >  That will somewhat contradict the tick-tock philosphy of stable odd
> releases but would be more realistic as every big change needs time to
> stabilise. Its slightly unfair, if users are kept in confused state till
> the strategy matures and starts delivering solid stable builds.
> > I think the question is more appropriate in dev list so I have kept it
> here.
> > ThanksAnuj
> > Sent from Yahoo Mail on Android
> >
> >  On Mon, 11 Apr, 2016 at 11:39 PM, Aleksey Yeschenko
> wrote:  The answer will depend on how conservative you are.
> >
> > The most conservative choice overall would be to go with the 2.2.x line.
> >
> > 3.0.x if you want to the new nice and shiny 3.0 things, but can tolerate
> some risk (the branch has a lot of relatively new core code, and hasn’t yet
> been tried out by as many users as the 2.x branch had).
> >
> > The latest odd 3.x if you want the shiniest (3.5 to be released soon,
> with features like the new SASI secondary indexes support). Also, there
> hasn’t yet been that much divergence between 3.0.x and 3.x, so risk levels
> are around the same, so long as you limit yourself to only the features
> present in 3.0.x.
> >
> > Either way, make sure to properly test whatever release you go for in
> staging first, as Michael says, and you’ll be alright.
> >
> > --
> > AY
> >
> > On 11 April 2016 at 18:42:31, Anuj Wadehra
> (anujw_2...@yahoo.co.in.invalid) wrote:
> >
> > Can someone help me with this one?
> > ThanksAnuj
> >
> > Sent from Yahoo Mail on Android
> >
> > On Sun, 10 Apr, 2016 at 11:07 PM, Anuj Wadehra
> wrote: Hi,
> > Tick-Tock release strategy in 3.x was a good intiative to ensure
> frequent & stable releases. While odd releases are supposed to get all the
> bug fixes and should be most stable, many people like me, who got used to
> the comforting "production ready/stable" tag on Apache website,  are still
> reluctant to take latest 3.x odd releases into production. I think the
> hesitation is somewhat justified as processes often take time to mature.
> > So here I would like to ask the experts, people who know the ground
> situation, people who actively develop it and manage it. Considering the
> current scenario, What should be a resonable criteria for taking 3.x
> releases in production?
> >
> >
> > ThanksAnuj
> >
> >
> >
> >
> >
>
>
>

-- 


--

Re: NGCC 2016

[Jonathan Ellis]

Just a heads up that I've sent out acceptances for 52 people.  If you're
surprised that you didn't get one, please resubmit your information.

Also, that leaves us with room for about ten more, so if you were on the
fence about coming, go for it!

On Thu, Mar 10, 2016 at 10:22 PM, Jonathan Ellis  wrote:

> Yes, we'll make the registration deadline April 9 and send out replies
> after that.
>
> On Thu, Mar 10, 2016 at 6:43 PM, Dikang Gu  wrote:
>
>> Awesome! Just registered. I did not attend before, shall I expect to get
>> response some time later?
>>
>> Thanks
>> DIkang.
>>
>> On Thu, Mar 10, 2016 at 2:09 PM, Jonathan Ellis 
>> wrote:
>>
>> > And, it's actually June 9-10.  Correct on the form.  Sorry!
>> >
>> > On Thu, Mar 10, 2016 at 3:48 PM, Jonathan Ellis 
>> wrote:
>> >
>> > > ... and here's an actual working link: http://goo.gl/forms/Ec6DdNFD6h
>> > >
>> > > On Thu, Mar 10, 2016 at 3:47 PM, Jonathan Ellis 
>> > wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >> This year's Next Generation Cassandra Conference will be June 8-9
>> (yes,
>> > >> two days!) in Austin, Texas.  The first day will be a single track of
>> > >> prepared presentations, similar to previous years'.  The second day
>> > will be
>> > >> reserved for followup discussions in an "unconference" format.
>> > >>
>> > >> Details and registration:
>> > >>
>> >
>> https://docs.google.com/forms/d/11CMRuTlUeyPd_X9Oo11X7_xx8RAJEzZ-HOVc5p079c8/edit?usp=forms_home=true
>> > >>
>> > >> See you there!
>> > >>
>> > >> --
>> > >> Jonathan Ellis
>> > >> Project Chair, Apache Cassandra
>> > >> co-founder, http://www.datastax.com
>> > >> @spyced
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Jonathan Ellis
>> > > Project Chair, Apache Cassandra
>> > > co-founder, http://www.datastax.com
>> > > @spyced
>> > >
>> >
>> >
>> >
>> > --
>> > Jonathan Ellis
>> > Project Chair, Apache Cassandra
>> > co-founder, http://www.datastax.com
>> > @spyced
>> >
>>
>>
>>
>> --
>> Dikang
>>
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

Re: Criteria for upgrading to 3.x releases in PROD

[Anuj Wadehra]

I am sorry but here, I am not expecting thousands to decide a stable version 
for my use case. I have a serious question about publishing some info on the 
Apache website. As dev list has active contributors, I posted it here. If not 
this forum, Whats the best way to put your suggestions regarding Apache content 
and initiate a meaningful and conclusive discussion thread? 

ThanksAnuj

Sent from Yahoo Mail on Android 
 
  On Mon, 18 Apr, 2016 at 11:27 PM, Michael 
Kjellman wrote:   This is best for the users 
list. Test the releases yourself and then decide when it's ready for your use 
case, ops team, and organization. This is a personal decision and not one for 
*thousands* of others on this mailing list to make for you.

best,
kjellman

> On Apr 18, 2016, at 10:54 AM, Anuj Wadehra  
> wrote:
> 
> Hi All,
> For last several months, the "most stable version" question pops up on the 
> user mailing list and then people get all sorts of responses/suggestions..
> If you are conservative go for x if adventurous y..
> If you have good risk appetite go for x else y..
> If you want features go for x else y..
> 
> Unfortunately, all above responses dont help many users..but only reinforce 
> the low confidence in latest releases.Who wants to be adventurous in 
> Production? Who wants to test his risk appetite in Production? And who would 
> want features for stability in Production? Not many..I am sure.
> So my question is:
> Would it be a wise decision to mention the "most stable/production ready" 
> version (as it used to be before 3.x) on the Apache website till tick-tock 
> release strategy evolves and matures?
>  That will somewhat contradict the tick-tock philosphy of stable odd releases 
>but would be more realistic as every big change needs time to stabilise. Its 
>slightly unfair, if users are kept in confused state till the strategy matures 
>and starts delivering solid stable builds.
> I think the question is more appropriate in dev list so I have kept it here.
> ThanksAnuj
> Sent from Yahoo Mail on Android 
> 
>  On Mon, 11 Apr, 2016 at 11:39 PM, Aleksey Yeschenko 
>wrote:  The answer will depend on how conservative you are.
> 
> The most conservative choice overall would be to go with the 2.2.x line.
> 
> 3.0.x if you want to the new nice and shiny 3.0 things, but can tolerate some 
> risk (the branch has a lot of relatively new core code, and hasn’t yet been 
> tried out by as many users as the 2.x branch had).
> 
> The latest odd 3.x if you want the shiniest (3.5 to be released soon, with 
> features like the new SASI secondary indexes support). Also, there hasn’t yet 
> been that much divergence between 3.0.x and 3.x, so risk levels are around 
> the same, so long as you limit yourself to only the features present in 3.0.x.
> 
> Either way, make sure to properly test whatever release you go for in staging 
> first, as Michael says, and you’ll be alright.
> 
> -- 
> AY
> 
> On 11 April 2016 at 18:42:31, Anuj Wadehra (anujw_2...@yahoo.co.in.invalid) 
> wrote:
> 
> Can someone help me with this one?  
> ThanksAnuj  
> 
> Sent from Yahoo Mail on Android  
> 
> On Sun, 10 Apr, 2016 at 11:07 PM, Anuj Wadehra wrote: 
> Hi,  
> Tick-Tock release strategy in 3.x was a good intiative to ensure frequent & 
> stable releases. While odd releases are supposed to get all the bug fixes and 
> should be most stable, many people like me, who got used to the comforting 
> "production ready/stable" tag on Apache website,  are still reluctant to take 
> latest 3.x odd releases into production. I think the hesitation is somewhat 
> justified as processes often take time to mature.  
> So here I would like to ask the experts, people who know the ground 
> situation, people who actively develop it and manage it. Considering the 
> current scenario, What should be a resonable criteria for taking 3.x releases 
> in production?  
> 
> 
> ThanksAnuj  
> 
> 
> 
> 
> 

  

Re: Criteria for upgrading to 3.x releases in PROD

[Anuj Wadehra]

Hi All,
For last several months, the "most stable version" question pops up on the user 
mailing list and then people get all sorts of responses/suggestions..
If you are conservative go for x if adventurous y..
If you have good risk appetite go for x else y..
If you want features go for x else y..

Unfortunately, all above responses dont help many users..but only reinforce the 
low confidence in latest releases.Who wants to be adventurous in Production? 
Who wants to test his risk appetite in Production? And who would want features 
for stability in Production? Not many..I am sure.
So my question is:
Would it be a wise decision to mention the "most stable/production ready" 
version (as it used to be before 3.x) on the Apache website till tick-tock 
release strategy evolves and matures?
 That will somewhat contradict the tick-tock philosphy of stable odd releases 
but would be more realistic as every big change needs time to stabilise. Its 
slightly unfair, if users are kept in confused state till the strategy matures 
and starts delivering solid stable builds.
I think the question is more appropriate in dev list so I have kept it here.
ThanksAnuj
Sent from Yahoo Mail on Android 
 
  On Mon, 11 Apr, 2016 at 11:39 PM, Aleksey Yeschenko 
wrote:   The answer will depend on how conservative you are.

The most conservative choice overall would be to go with the 2.2.x line.

3.0.x if you want to the new nice and shiny 3.0 things, but can tolerate some 
risk (the branch has a lot of relatively new core code, and hasn’t yet been 
tried out by as many users as the 2.x branch had).

The latest odd 3.x if you want the shiniest (3.5 to be released soon, with 
features like the new SASI secondary indexes support). Also, there hasn’t yet 
been that much divergence between 3.0.x and 3.x, so risk levels are around the 
same, so long as you limit yourself to only the features present in 3.0.x.

Either way, make sure to properly test whatever release you go for in staging 
first, as Michael says, and you’ll be alright.

-- 
AY

On 11 April 2016 at 18:42:31, Anuj Wadehra (anujw_2...@yahoo.co.in.invalid) 
wrote:

Can someone help me with this one?  
ThanksAnuj  

Sent from Yahoo Mail on Android  

On Sun, 10 Apr, 2016 at 11:07 PM, Anuj Wadehra wrote: 
Hi,  
Tick-Tock release strategy in 3.x was a good intiative to ensure frequent & 
stable releases. While odd releases are supposed to get all the bug fixes and 
should be most stable, many people like me, who got used to the comforting 
"production ready/stable" tag on Apache website,  are still reluctant to take 
latest 3.x odd releases into production. I think the hesitation is somewhat 
justified as processes often take time to mature.  
So here I would like to ask the experts, people who know the ground situation, 
people who actively develop it and manage it. Considering the current scenario, 
What should be a resonable criteria for taking 3.x releases in production?   


ThanksAnuj  




  

Re: C-136A Questionnaire for Apache Cassandra

[Jack Krupansky]

Here's a recent security assessment discussion - list of questions,
proposed response, and discussion, which you might find helpful, courtesy
of Oleg Yusim:
https://docs.google.com/document/d/13-yu-1a0MMkBiJFPNkYoTd1Hzed9tgKltWi6hFLZbsk/edit?ts=56c3a130#heading=h.xq6exsjcda8


-- Jack Krupansky

On Mon, Apr 18, 2016 at 7:31 AM, Johnson, Tom (ES & CSO) <
thomas.johns...@ngc.com> wrote:

> Apache Cassandra Support,
>
>
>
> In order to install this software on our servers, I need help from Planet
> Cassandra in completing the attached questionnaire for Northrop Grumman
> Information Security.  Please provide as much detail as possible for all
> questions.  If you have any questions for me, please let me know.  Thanks.
>
>
>
>
>
> *Thomas (Tom) Johnson*
>
> *Software Development Analyst*
>
> *Engineering Tools Support Team (ETST)*
>
> *Northrop Grumman Information Technology*
>
> *Office: 321-674-3168 <321-674-3168>*
>
> *thomas.johns...@ngc.com *
>
>
>

C-136A Questionnaire for Apache Cassandra

[Johnson, Tom (ES & CSO)]

Apache Cassandra Support,

In order to install this software on our servers, I need help from Planet 
Cassandra in completing the attached questionnaire for Northrop Grumman 
Information Security.  Please provide as much detail as possible for all 
questions.  If you have any questions for me, please let me know.  Thanks.


Thomas (Tom) Johnson
Software Development Analyst
Engineering Tools Support Team (ETST)
Northrop Grumman Information Technology
Office: 321-674-3168
thomas.johns...@ngc.com



Apache Cassandra C-136A_Blank.docx
Description: Apache Cassandra C-136A_Blank.docx

Re: CQL spec error: COUNT(column)

[Jack Krupansky]

No, I didn't test, I was just reading the code, but I hadn't checked for
all occurrences of K_COUNT, so I hadn't noticed that it also occurs in the
allowedFunctionName grammar production rule. And I found the code that
dynamically creates a count function for each type here:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/AggregateFcts.java#L885

So, sorry for the confusion. Some comments in the grammar would have helped.

And it's not in the DataStax doc, but that's another issue I can follow up
on.

-- Jack Krupansky

On Mon, Apr 18, 2016 at 10:12 AM, Benjamin Lerer <
benjamin.le...@datastax.com> wrote:

> May be I misunderstood you.
> Do you mean that you tested it and that it is not working on the version
> you used?
>
> On Mon, Apr 18, 2016 at 3:50 PM, Jack Krupansky 
> wrote:
>
> > The CQL spec for COUNT says:
> >
> > "It also can be used to count the non null value of a given column.
> > Example:
> >
> > SELECT COUNT(scores) FROM plays;"
> >
> > But, the parser only recognizes COUNT(*) and COUNT(1).
> >
> > See:
> > https://cassandra.apache.org/doc/cql3/CQL-3.0.html
> > https://github.com/apache/cassandra/blob/trunk/src/antlr/Parser.g#L276
> >
> > Does this need a Jira, or can somebody just fix it to avoid the
> paperwork?
> >
> > Or, was this actually supposed to  work and the bug is some missing
> > implementation?
> >
> > Thanks.
> >
> > -- Jack Krupansky
> >
>

Re: CQL spec error: COUNT(column)

[Benjamin Lerer]

Hi Jack,

You are looking at the wrong place. count() is a native
function. There nothing specific for it in the parser syntax.

Benjamin


On Mon, Apr 18, 2016 at 3:50 PM, Jack Krupansky 
wrote:

> The CQL spec for COUNT says:
>
> "It also can be used to count the non null value of a given column.
> Example:
>
> SELECT COUNT(scores) FROM plays;"
>
> But, the parser only recognizes COUNT(*) and COUNT(1).
>
> See:
> https://cassandra.apache.org/doc/cql3/CQL-3.0.html
> https://github.com/apache/cassandra/blob/trunk/src/antlr/Parser.g#L276
>
> Does this need a Jira, or can somebody just fix it to avoid the paperwork?
>
> Or, was this actually supposed to  work and the bug is some missing
> implementation?
>
> Thanks.
>
> -- Jack Krupansky
>

Re: CQL spec error: COUNT(column)

[Benjamin Lerer]

May be I misunderstood you.
Do you mean that you tested it and that it is not working on the version
you used?

On Mon, Apr 18, 2016 at 3:50 PM, Jack Krupansky 
wrote:

> The CQL spec for COUNT says:
>
> "It also can be used to count the non null value of a given column.
> Example:
>
> SELECT COUNT(scores) FROM plays;"
>
> But, the parser only recognizes COUNT(*) and COUNT(1).
>
> See:
> https://cassandra.apache.org/doc/cql3/CQL-3.0.html
> https://github.com/apache/cassandra/blob/trunk/src/antlr/Parser.g#L276
>
> Does this need a Jira, or can somebody just fix it to avoid the paperwork?
>
> Or, was this actually supposed to  work and the bug is some missing
> implementation?
>
> Thanks.
>
> -- Jack Krupansky
>

CQL spec error: COUNT(column)

[Jack Krupansky]

The CQL spec for COUNT says:

"It also can be used to count the non null value of a given column. Example:

SELECT COUNT(scores) FROM plays;"

But, the parser only recognizes COUNT(*) and COUNT(1).

See:
https://cassandra.apache.org/doc/cql3/CQL-3.0.html
https://github.com/apache/cassandra/blob/trunk/src/antlr/Parser.g#L276

Does this need a Jira, or can somebody just fix it to avoid the paperwork?

Or, was this actually supposed to  work and the bug is some missing
implementation?

Thanks.

-- Jack Krupansky