eates
>> inconsistencies across tools and users. The tradeoffs you've listed are
>> worth considering, but in my opinion adding 2 new ways to accomplish the
>> same thing hurts the project more than it helps.
>> >
>> > > - I'd like to see a symmetr
means we need more documentation and creates
> inconsistencies across tools and users. The tradeoffs you've listed are
> worth considering, but in my opinion adding 2 new ways to accomplish the
> same thing hurts the project more than it helps.
> >
> > > - I'd like
ey would perform full cluster scans. For other types
of inequality such as c > 5, we'd need #4. #3 would make non-pk equality
searches friendly to large clusters, and #5 would help with the more
advanced types of SQL-ish queries.
Thanks for bringing this up, it's an interesting t
Hi everybody,
CQL appears to be inconsistent in how it handles predicates.
One type of inconsistencies is that some operators can be used in some
places but not in others or on some expressions but not others.
For example:
- != can be used in LWT conditions but not elsewhere
- Token
Thanks everyone for comments. I would like to close this discussion if there
are no further comments and continue with the PR for code changes. I prefer
‘LIST SUPERUSERS’ cql command, please let me know if you prefer different
command/option.
> On Mar 1, 2024, at 12:44 PM, Sam Tunnicli
ractical level,
dynamically setting the is_super column based on role assignment doesn't work
as proposed because it can't differentiate between inherited and granted
status).
What Shailaja is proposing is essentially just some CQL sugar to expose what
Roles::hasSuperUserStatus does inter
need a transaction for that, because it can happen to any
column of almost any CQL query. For example, state of login/options/datacenters
etc can also change while we are processing a query. From my understanding it’s
acceptable that user runs the same query twice and sees difference in the
output
| False |False | null |
>>> null
>>> role11 | False |False | {'role1'} |
>>> null
>>> super1 | False | True | null |
null
>> role1 | False |False | {'super1'} |
>> null
>>
>>
>> Thanks,
>> Shailaja
>>
>>
>>> On Feb 29, 2024, at 2:11 AM, guo Maxwell >> <mailto:cclive1.
ks,
Shailaja
On Feb 29, 2024, at 2:11 AM, guo Maxwell
wrote:
Hi ,
1. can this cql "SELECT role from system_auth.roles where
is_superuser = True ALLOW FILTERING ;" meet your needs if the
user to execute the cql have the right to do so ？
2. I thin
| {'super1'} |
> null
>
>
> Thanks,
> Shailaja
>
>
> On Feb 29, 2024, at 2:11 AM, guo Maxwell wrote:
>
> Hi ,
> 1. can this cql "SELECT role from system_auth.roles where is_superuser =
> True ALLOW FILTERING ;&quo
| null |
null
role1 | False |False | {'super1'} |
null
Thanks,
Shailaja
> On Feb 29, 2024, at 2:11 AM, guo Maxwell wrote:
>
> Hi ,
> 1. can this cql "SELECT role from system_auth.
Hi ,
1. can this cql "SELECT role from system_auth.roles where is_superuser =
True ALLOW FILTERING ;" meet your needs if the user to execute the cql
have the right to do so ？
2. I think may be we can also add the ability to filter on list role/user
grammar, for example : list user w
orming
their own checks (for example, Sidecar). So I am proposing a new CQL command
LIST SUPERUSERS, which lists all roles having superuser status (acquired as
well). We will ensure that the user running this command has DESCRIBE
permission on root roles resource, i.e, to run this command user mus
sh the same
> thing hurts the project more than it helps.
>
> > - I'd like to see a symmetry between the JMX and CQL APIs, so that users
> > will have a sense of the commands they are using and are less
> likely to check the documentation;
>
> I've worked with a cou
are
worth considering, but in my opinion adding 2 new ways to accomplish the
same thing hurts the project more than it helps.
> - I'd like to see a symmetry between the JMX and CQL APIs, so that users
will have a sense of the commands they are using and are less
likely to check the do
https://issues.apache.org/jira/browse/CASSANDRA-14572
This is to observe the running configuration and all available metrics:
e.g. select * from system_views.thread_pools;
I hope both of the issues above will become part of the trunk branch
before we move on to the CQL management commands. In this
appetite to remove JMX, at least not
> for anyone that would have to rework their entire admin control plane, plus
> whatever is out there in OSS provisioning tools like puppet / chef / etc
> that rely on JMX. I see no value whatsoever in removing it.
>
> I should p
have to rework their entire admin control plane, plus
whatever is out there in OSS provisioning tools like puppet / chef / etc
that rely on JMX. I see no value whatsoever in removing it.
I should probably have phrased my earlier email a bit differently. Maybe
this is better:
Fundamentally, I
or the project if administration is
>> fully done over CQL and we have a consistent, single way of doing things.
> Strongly agree here. With 2 caveats:
> Supporting backwards compat, especially for automated ops (i.e. nodetool,
> JMX, etc), is crucial. Painful, but crucial.
> We need someth
> Fundamentally, I think it's better for the project if administration is fully
> done over CQL and we have a consistent, single way of doing things.
Strongly agree here. With 2 caveats:
1. Supporting backwards compat, especially for automated ops (i.e. nodetool,
JMX, etc), is cruci
I like the idea of the ability to execute certain commands via CQL, but I
think it only makes sense for the nodetool commands that cause an action to
take place, such as compact or repair. We already have virtual tables, I
don't think we need another layer to run informational queries.
ke an agent part in-tree, this should
be carefully considered for the flexibility which we may lose, as we
will not be able to change the agent part within the sidecar. The only
closest change I can see is that we can remove the interceptor part
once the CQL command interface is available. I sugge
an it ensure that commands are executed against the
> desired Cassandra instance?
Clients are expected to set the node for the given CQL statement in cases like
this; see docstring for example:
https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss
Hi Maxim,
I think this CEP is a great start to viewing Cassandra operations in a
different way! However, I have a few questions about it.
- How are the results of the commands expressed to the CQL client? Since
the command is being treated as CQL, I guess it will be rows, right? If
yes
d new implementation which would be partially inspired by our agent? Or
would the project integrate our agent code in-tree or as a dependency?
The latter would require of course changes to remove the CQL interceptor
and run the queries naturally against Cassandra, along with extracting just
the agent withou
Hi Maxim,
Thanks for working on this CEP!
The CEP addresses some of the features we have been discussing for Cassandra
Sidecar. For example, a dedicated admin port, moving towards more CQL-like
interfacing with Cassandra, among others.
I think virtual tables intended to bring the gap down
t the
k8ssandra-management-api fits in perfectly into the design that we
have. A few notes on both of these topics, read on.
Admin port (Service port)
For the initial implementation, a dedicated admin port is not required
because these changes do not add any new API consumers. New CQL
management op
Hi,
I originally worked on the management API sidecar mentioned above.
I'm excited to see there's renewed interest in the cql for ops concept.
Though it currently uses an agent to inject the local socket for cql
(so it can be used by older versions of Apache Cassandra),
Similar logi
vember 17, 2023 4:06 PM
To: dev
Subject: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API
Hi Maxim,
Thanks for putting this CEP together! This is a great start. I have gone over
the CEP and there is one thing that stuck out to me.
Among the 'basic requirements', I see y
improve the C* management approach we have as
> a whole. This approach aims to make all Cassandra management commands
> accessible via CQL, but not only that.
>
> The problem of making commands accessible via CQL presents a complex
> challenge, especially if we aim to minimi
do similar things. I especially like how they have a local
> database socket where a sidecar can easily access cassandra and execute cql
> commands without the need of a service account like your example suggests.
>
> The syntax they adopted (see for instance
> h
Hi Maxim,
We have adopted/forked the agent part of the
https://github.com/k8ssandra/management-api-for-apache-cassandra project which
aims to do similar things. I especially like how they have a local database
socket where a sidecar can easily access cassandra and execute cql commands
without
This approach aims to make all Cassandra management commands
accessible via CQL, but not only that.
The problem of making commands accessible via CQL presents a complex
challenge, especially if we aim to minimize code duplication across
the implementation of management operations for different API
:04 Doug Rohrer napisał(a):
>
> +1 (nb)
>
> > On May 8, 2023, at 4:52 AM, Piotr Kołaczkowski
> > wrote:
> >
> > Let's vote.
> >
> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
> >
> > Piotr Kołaczkowski
> > e. pkola...@datastax.com
> > w. www.datastax.com
>
+1 (nb)
On Fri, 12 May 2023 at 14:05, Doug Rohrer wrote:
> +1 (nb)
>
> > On May 8, 2023, at 4:52 AM, Piotr Kołaczkowski
> wrote:
> >
> > Let's vote.
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+o
+1 (nb)
> On May 8, 2023, at 4:52 AM, Piotr Kołaczkowski wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
>>
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>>>
>>> Piotr Kołaczkowski
>>> e. pkola...@datastax.com
>>> w. www.datastax.com
>>
>>
+1 (nb)
On 2023/05/10 14:10:06 Jeremiah D Jordan wrote:
> +1 nb
>
> > On May 8, 2023, at 3:52 AM, Piotr Kołaczkowski
> > wrote:
> >
> > Let's vote.
> >
> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+op
+1 nb
> On May 8, 2023, at 3:52 AM, Piotr Kołaczkowski wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
+1
Kind Regards,
Brandon
On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
+1
On Wed, 10 May 2023 at 0:40, Dinesh Joshi wrote:
> +1
>
> > On May 8, 2023, at 1:52 AM, Piotr Kołaczkowski
> wrote:
> >
> > Let's vote.
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
> >
>
+1
> On May 8, 2023, at 1:52 AM, Piotr Kołaczkowski wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
+1
On 10/5/23 3:57, Jonathan Ellis wrote:
+1
On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
wrote:
Let's vote.
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
Piotr Kołaczkowski
e. pkola...@datastax.com
w. www.datastax.com
+1
On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
wrote:
> Let's vote.
>
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
>
--
Jonathan Ellis
co-
+1
On Tue, May 9, 2023, at 2:42 PM, Patrick McFadin wrote:
> +1
>
> On Tue, May 9, 2023 at 10:58 AM Caleb Rackliffe
> wrote:
>> +1
>>
>> On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
>> wrote:
>>> Let's vote.
>>>
>>>
+1
On Tue, May 9, 2023 at 10:58 AM Caleb Rackliffe
wrote:
> +1
>
> On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
> wrote:
>
>> Let's vote.
>>
>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>>
>
+1
On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
wrote:
> Let's vote.
>
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
>
Let's vote.
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
Piotr Kołaczkowski
e. pkola...@datastax.com
w. www.datastax.com
; which is IMHO a good thing because that wouldn't need any storage
> format changes.
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
>
> wt., 11 kwi 2023 o 21:55 Caleb Rackliffe
> napisał(a):
> >
> > +1 to the proposal from a CQL pe
Hello,
I'd like to start a vote on adding the NOT operator to CQL.
CEP doc:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
Thanks,
Piotr
Piotr Kołaczkowski
e. pkola...@datastax.com
w. www.datastax.com
changes.
Piotr Kołaczkowski
e. pkola...@datastax.com
w. www.datastax.com
wt., 11 kwi 2023 o 21:55 Caleb Rackliffe napisał(a):
>
> +1 to the proposal from a CQL perspective
>
> However, whether we do this in the context of simple partition restriction, a
> global index query, or a partit
G WITHIN PARTITION, I think we could just add a guardrail to directly disallow those queries, without needing to add the WITHIN PARTITION clause to the CQL grammar.On Thu, 13 Apr 2023 at 11:11, Henrik Ingo <henrik.i...@datastax.com> wrote:On Thu, Apr 13, 2023 at 10:20 AM Miklosovic, Stefan <stef
d within
> partition filtering wouldn't require AF.
>
> Regarding adding a new ALLOW FILTERING WITHIN PARTITION, I think we could
> just add a guardrail to directly disallow those queries, without needing to
> add the WITHIN PARTITION clause to the CQL grammar.
>
> On Thu
ion is used. So both within row and within partition filtering wouldn't require AF.Regarding adding a new ALLOW FILTERING WITHIN PARTITION, I think we could just add a guardrail to directly disallow those queries, without needing to add the WITHIN PARTITION clause to the CQL grammar.On Thu, 13
tition keys, if a IN restriction is used. So both within row and within
partition filtering wouldn't require AF.
Regarding adding a new ALLOW FILTERING WITHIN PARTITION, I think we could
just add a guardrail to directly disallow those queries, without needing to
add the WITHIN PARTITION clause to the
On Thu, Apr 13, 2023 at 10:20 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> Somebody correct me if I am wrong but "partition key" itself is not enough
> (primary keys = partition keys + clustering columns). It will require ALLOW
> FILTERING when clustering columns are not specifie
.
From: Miklosovic, Stefan
Sent: Thursday, April 13, 2023 9:20
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-29 CQL NOT Operator
Somebody correct me if I am wrong but "partition key" itself is not enough
(primary keys = partition keys + clustering columns). It wi
ey (p1, c1));
select * from ks.tb where p1 = 1 and col1 = 2; // this will require allow
filtering
The documentation seems to omit this fact.
From: Henrik Ingo
Sent: Thursday, April 13, 2023 8:53
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-29 CQL NO
Wait... Why would anything require ALLOW FILTERING if the partition key is
defined? That seems to contradict documentation:
https://cassandra.apache.org/doc/latest/cassandra/cql/dml.html#allow-filtering
Also my intuition / expectation matches what the manual says.
henrik
On Fri, Apr 7, 2023 at
+1 to the proposal from a CQL perspective
*However*, whether we do this in the context of simple partition
restriction, a global index query, or a partition-restricted index query,
the NOT operator is most likely to be useful only in a post-filtering
capacity. (ex. WHERE indexed_set CONTAINS
ołaczkowski > > <mailto:pkola...@datastax.com>> wrote:
>> >
>> > Hi everyone!
>> >
>> > I created a new CEP for adding NOT support to the query language and
>> > want to start discussion around it:
>> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>> >
>> > Happy to get your feedback.
>> > --
>> > Piotr
>>
OT IN for partition keys).
>
> > On Apr 4, 2023, at 2:28 AM, Piotr Kołaczkowski
> wrote:
> >
> > Hi everyone!
> >
> > I created a new CEP for adding NOT support to the query language and
> > want to start discussion around it:
> >
> https://cwiki.a
> Hi everyone!
>
> I created a new CEP for adding NOT support to the query language and
> want to start discussion around it:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Happy to get your feedback.
> --
> Piotr
Hi everyone!
I created a new CEP for adding NOT support to the query language and
want to start discussion around it:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
Happy to get your feedback.
--
Piotr
> Actually, this one https://issues.apache.org/jira/browse/CASSANDRA-18306
>
>
> From: Miklosovic, Stefan
> Sent: Monday, March 13, 2023 13:26
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Remove deprecated CQL functions da
Actually, this one https://issues.apache.org/jira/browse/CASSANDRA-18306
From: Miklosovic, Stefan
Sent: Monday, March 13, 2023 13:26
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Remove deprecated CQL functions dateof and
unixtimestampof on 5.0
I am +1.
Could you please link the ticket to
https://issues.apache.org/jira/browse/CASSANDRA-17973 ?
Thanks
From: Andrés de la Peña
Sent: Monday, March 13, 2023 13:22
To: dev@cassandra.apache.org
Subject: [DISCUSS] Remove deprecated CQL functions
The CQL functions "dateof" and "unixtimestampof" were deprecated on
Cassandra 2.2.0, almost eight years ago [1]. They were deprecated in favour
of the then new "totimestamp" and "tounixtimestamp" functions.
I think that we can finally remove those functions
meant snake case and need coffee.
> >>>
> >>>> On Thu, Nov 10, 2022, 7:26 AM Brandon Williams
> wrote:
> >>>
> >>>> +1 on camel case and aliases for compatibility.
> >>>>
> >>>> On Thu, Nov 10, 2022, 6:21 AM
;
>>>> On Thu, Nov 10, 2022, 7:26 AM Brandon Williams wrote:
>>>
>>>> +1 on camel case and aliases for compatibility.
>>>>
>>>> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña
>>>> wrote:
>>>>
>>>>> I
> >> wrote:
> >>
> >>> It seems we don't have a clear convention on how to name CQL native
> >>> functions.
> >>>
> >>> Most native functions are named all lower case, without underscore nor
> >>> hyphen to separa
, 2022, 7:26 AM Brandon Williams wrote:
>
>> +1 on camel case and aliases for compatibility.
>>
>> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña
>> wrote:
>>
>>> It seems we don't have a clear convention on how to name CQL native
>>>
I too meant snake case and need coffee.
On Thu, Nov 10, 2022, 7:26 AM Brandon Williams wrote:
> +1 on camel case and aliases for compatibility.
>
> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña
> wrote:
>
>> It seems we don't have a clear convention on how to na
snake_case as the convention and use camelCase aliases for
> compatibility.
>
> On Thu, 10 Nov 2022 at 13:26, Brandon Williams wrote:
>
>> +1 on camel case and aliases for compatibility.
>>
>> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña
>> wrote:
>>
>&g
camel case and aliases for compatibility.
>
> On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña
> wrote:
>
>> It seems we don't have a clear convention on how to name CQL native
>> functions.
>>
>> Most native functions are named all lower case, without unders
+1 on camel case and aliases for compatibility.
On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña
wrote:
> It seems we don't have a clear convention on how to name CQL native
> functions.
>
> Most native functions are named all lower case, without underscore nor
> hyphen to se
seems to be like a
> good idea.
>
>
> From: Andrés de la Peña
> Sent: Thursday, November 10, 2022 13:20
> To: dev@cassandra.apache.org
> Subject: Naming conventions for CQL native functions
>
> NetApp Security WARNING: This is a
Subject: Naming conventions for CQL native functions
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
It seems we don't have a clear convention on how to name CQL native functions.
Most n
+1 to consolidating on one option and aliasing where needed. Avoiding
camel-case to spare the user the quoting seems also like a good idea to me.
On 10/11/22 13:20, Andrés de la Peña wrote:
It seems we don't have a clear convention on how to name CQL native
functions.
Most native func
It seems we don't have a clear convention on how to name CQL native
functions.
Most native functions are named all lower case, without underscore nor
hyphen to separate words. That's the case, for example, of "intasblob" or
"blobasint".
We also have some fun
se. Where did you
>> find that file?
>>
>> At first glance effectively something looks wrong in the syntax. The
>> construct ((4 ,5 ), 6, (7, 8)) should be legal in CQL.
>>
>> Le jeu. 10 mars 2022 à 06:50, Claude Warren <
>> claude.war...@instaclustr.com
, 10 Mar 2022 at 09:38, Benjamin Lerer wrote:
> Hi Claude,
>
> I am not aware of the CqlParser.g4 file in our code base. Where did you
> find that file?
>
> At first glance effectively something looks wrong in the syntax. The
> construct ((4 ,5 ), 6, (7, 8)) should be legal i
Hi Claude,
I am not aware of the CqlParser.g4 file in our code base. Where did you
find that file?
At first glance effectively something looks wrong in the syntax. The
construct ((4 ,5 ), 6, (7, 8)) should be legal in CQL.
Le jeu. 10 mars 2022 à 06:50, Claude Warren
a écrit :
> I have b
I have been looking at CqlParser.g4 file for cql3 and have a question
about assignment tuples. The assignment tuple is defined as :
assignmentTuple
: syntaxBracketLr (
constant ((syntaxComma constant)* | (syntaxComma assignmentTuple)*) |
assignmentTuple (syntaxComma assignm
it is great that you raised this. That light file in the patch for
> CASSANDRA-16763 been migrated to an adoc file, and now available on the
> website¹, and probably not what we want if we are not yet bundling docs into
> releases…
>
> [1] https://cassandra.apache.org/doc/late
https://cassandra.apache.org/doc/latest/cassandra/cql/cql_singlefile.html
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Thx for the reply Mick,
I will join the loop in those tickets.
On 9/8/21 14:14, Mick Semb Wever wrote:
>> And shouldn't it be preferable to replace that skinny
>> page with a local copy of the CQL docs?
>>
>
> Our binaries don't ship with all-the-docs.
>
>
>
> And shouldn't it be preferable to replace that skinny
> page with a local copy of the CQL docs?
>
Our binaries don't ship with all-the-docs.
This has been discussed during the work for the new website and its new
antora build system: CASSANDRA-16761 and CASSANDRA-16763
Hi all,
working on CASSANDRA-13047 we noticed there's a skinny CQL help file
in-tree to where the 'help' command takes you to. This, iiuc, is to
support help on topics for envs with reduced connectivity where they
can't go online.
Is this correct? And shouldn't it be p
Just filed https://issues.apache.org/jira/browse/CASSANDRA-16233, but
wanted to bring to the dev list first.
In 2.1 "replace" was not a reserved word but this was changed in 2.2;
making "replace" a reserved word breaks users upgrading to the 3.x line as
their queries no longer parse.
I filed a pa
I think getting the CQL parser submitted upstream to pygments is a great
idea.
Anyone have experience with pygments?
On Mon, Jun 1, 2020 at 6:34 AM Mike Adamson wrote:
> The correct code location is:
>
> https://github.com/apache/cassandra/tree/trunk/doc/source/_util
>
> On Mon
The correct code location is:
https://github.com/apache/cassandra/tree/trunk/doc/source/_util
On Mon, 1 Jun 2020 at 14:21, Lorina Poland wrote:
> Some time back, someone (Sylvain?) wrote some code to use CQL with
> pygments. Can I interest anyone in picking up that work, perhaps doin
Some time back, someone (Sylvain?) wrote some code to use CQL with pygments.
Can I interest anyone in picking up that work, perhaps doing some update and
submitting it upstream to pygments.org? It would be exceedingly helpful to me
personally (for C* documentation work), but also a wider
le to make it less invasive
> of
> > a change while providing access to the TableCQLHelper output (and fixing
> > it).
> >
> > The other is to add a DESCRIBE command to the cql protocol or query
> parser
> > so that the command would act same across all drivers as it do
sive of
> a change while providing access to the TableCQLHelper output (and fixing
> it).
>
> The other is to add a DESCRIBE command to the cql protocol or query parser
> so that the command would act same across all drivers as it does in cqlsh.
>
> In both cases it would return
to add a DESCRIBE command to the cql protocol or query parser
so that the command would act same across all drivers as it does in cqlsh.
In both cases it would return a ResultSet so from drivers perspective it
wont be too much different.
Since the original thought was a virtual table the existing
Done.
https://issues.apache.org/jira/browse/CASSANDRA-13656
- Original Message -
> Open a jira for it and lets change it?
>
>
> --
> Jeff Jirsa
>
>
> > On Jun 29, 2017, at 8:04 AM, Mike Adamson wrote:
> >
> > I've honestly no idea but it is still defaulting to false in Config.java.
Open a jira for it and lets change it?
--
Jeff Jirsa
> On Jun 29, 2017, at 8:04 AM, Mike Adamson wrote:
>
> I've honestly no idea but it is still defaulting to false in Config.java.
> I'm assuming it will change to defaulting to true when thrift is finally
> removed.
>
>> On Thu, 29 Jun 201
I've honestly no idea but it is still defaulting to false in Config.java.
I'm assuming it will change to defaulting to true when thrift is finally
removed.
On Thu, 29 Jun 2017 at 15:34 Tomas Repik wrote:
> Thanks Mike,
>
> now I remember this option, but I thought it was set to true by default.
1 - 100 of 324 matches
Mail list logo
