The reason for using OPTION keyword is that I want to provide users with
more choices .
The default behavior for copying a table is to copy the basic item of table
（column and their data type，mask，constraint），others thing belongs to the
table like option，views，trigger
are optional in my mind.
You a
Josh/Mick, where does that leave us? I’d like to start with the smaller
scope Josh described in his last email. We can tackle in-tree/stress
separately.
I was going to start working on getting signed ICLAs. Does that still sound
like the right next step? Or is that also not necessary unless we tak
I realise it’s out of scope, but to counterbalance all of the pro-decomposition messages I wanted to chime in with a strong -1. But we can debate that in a suitable context later.On 22 Oct 2024, at 16:36, Jordan West wrote:Agreed with the sentiment that decomposition is a good target but out of s
The problem is that when I do this minimal CQL which shows this feature:
CREATE TABLE ks.tb_copy LIKE ks.tb;
then you are saying that when I _do not_ specify WITH OPTIONS then I get
Cassandra's defaults. Only after I specify WITH OPTIONS, it would truly be
a copy.
This is not a good design. Beca
I just don't see OPTIONS as important. When I want to copy a table, I am
copying a table _with everything_. Options included, by default. Why would
I want to have a copy of a table with options different from the base one?
On Mon, Oct 21, 2024 at 3:55 PM Bernardo Botella <
conta...@bernardobotell
Agreed with the sentiment that decomposition is a good target but out of
scope here. I’m personally excited to see an in-tree repair scheduler and
am supportive of the approach shared here.
Jordan
On Tue, Oct 22, 2024 at 08:12 Dinesh Joshi wrote:
> Decomposing Cassandra may be architecturally d
Honestly, counting the letters was also a thing that happened to me but I
should admit that even with CASSANDRAANALYTICS we count the As…
My preference is CASSX
Seems shorter and less painful to read to me as a user.
Thanks
On Tue, 22 Oct 2024 at 11:18, Patrick McFadin wrote:
> CASS + NAM
CASS + NAME is my +1
TBH rarely with this be typed. Just copied and pasted. It has to be
clear that naming is different from the other projects and I think we
get it either way.
On Tue, Oct 22, 2024 at 8:15 AM Štefan Miklošovič
wrote:
>
> Something like this?
>
> CASSANDRA
> CASSPYTHON
> CASSGO
On Mon, Oct 21, 2024 at 9:18 AM David Capwell wrote:
> One thing to keep in mind is that larger clusters require you “smartly”
> split the ranges else you nuke your cluster… knowing how to split requires
> internal knowledge from the database which we could expose, but then we
> need to expose a
That seems reasonable for me.
On Tue, Oct 22, 2024 at 8:01 AM Brandon Williams wrote:
>
> I don't think underscore is an option from selfserve anyway. If we
> have to stick everything together then I think having fewer things is
> better, so we could drop the 'driver' and just name things like
>
Something like this?
CASSANDRA
CASSPYTHON
CASSGO
CASSJAVA
CASSSIDECAR
CASSANALYTICS
if we expand it would be like
CASSANDRA
CASSANDRAPYTHON
CASSANDRAGO
CASSANDRAJAVA
CASSANDRASIDECAR
CASSANDRAANALYTICS
I don't know ... the first form seems fine to me but that triple S in
CASSSIDECAR is strange.
Decomposing Cassandra may be architecturally desirable but that is not the
goal of this CEP. This CEP brings value to operators today so it should be
considered on that merit. We definitely need to have a separate
conversation on Cassandra's architectural direction.
On Tue, Oct 22, 2024 at 7:51 AM
I don't think underscore is an option from selfserve anyway. If we
have to stick everything together then I think having fewer things is
better, so we could drop the 'driver' and just name things like
CASSPYTHON. WDYT?
Kind Regards,
Brandon
On Tue, Oct 22, 2024 at 9:33 AM Štefan Miklošovič
wro
Definitely like this in C* itself. We only changed our proposal to putting
repair scheduling in the sidecar before because trunk was frozen for the
foreseeable future at that time. With trunk unfrozen and development on the
main process going at a fast pace I think it makes way more sense to
integr
So we will have stuff like
CASS_DRIVER_PYTHON and all tickets in CHANGES.txt as well as in the commit
messages will be like
CASS_DRIVER_PYTHON-1234
I checked (1) and there is not a single one which has underscores in its
name, now THAT would be a precedent, wouldn't it ...
(1)
https://issues.ap
This seems to be relevant documentation:
https://confluence.atlassian.com/adminjiraserver/changing-the-project-key-format-938847081.html
Martin
--
This email, including attached files, may contain confidential information
and is intended only for the use of the individual and/or entity to which
Well, I don't see any TLPs with anything but alphanumeric, and only
one of those contains a number.
Kind Regards,
Brandon
On Tue, Oct 22, 2024 at 9:12 AM Patrick McFadin wrote:
>
> I thought underscore was one of the allowed characters. Or it could be and
> has just been restricted in the admin
I thought underscore was one of the allowed characters. Or it could be and
has just been restricted in the admin regex.
On Tue, Oct 22, 2024 at 6:53 AM Brandon Williams wrote:
> It looks like I can create the subprojects myself with
> https://selfserve.apache.org but there is a small issue with
It looks like I can create the subprojects myself with
https://selfserve.apache.org but there is a small issue with the
bikeshed: JIRA projects must be alphanumeric only. So we can have
CASSDRIVERPYTHON but not CASS-DRIVER-PYTHON. I'm not a huge fan of
everything stuck together like that, but may
Hi,
> I'd really, really like to see us ship a Prom compatible metrics endpoint
out of the box in C* that has low overhead. All the current OSS metrics
exporters that I've seen have massive overhead. I'm specifically looking
for sub-10s collection on clusters with a thousand nodes and 500+ table
20 matches
Mail list logo
