Re: Welcome Maxim Muzafarov as Cassandra Committer

[Berenguer Blasi]

Welcome!

On 9/1/24 13:16, Maxim Muzafarov wrote:

Thank you all so much, I'm happy to be part of such an active
community and to be able to contribute to the product that is used all
over the world!

On Tue, 9 Jan 2024 at 12:33, Mike Adamson  wrote:

Congrats Maxim!!

On Tue, 9 Jan 2024, 10:41 Andrés de la Peña,  wrote:

Congrats, Maxim!

On Tue, 9 Jan 2024 at 03:45, guo Maxwell  wrote:

Congratulations, Maxim!

Francisco Guerrero  于2024年1月9日周二 09:00写道：

Congratulations, Maxim! Well deserved!

On 2024/01/08 18:19:04 Josh McKenzie wrote:

The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov has 
accepted
the invitation to become a committer.

Thanks for all the hard work and collaboration on the project thus far, and 
we're all looking forward to working more with you in the future. 
Congratulations and welcome!

The Apache Cassandra PMC members

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Derek Chen-Becker]

Actually, now that I'm looking at the original email on my browser and not
my phone (and can see the formatting properly), I think we have the
nomenclature backward here. Left-alignment in the printing world means that
text in each cell starts at the left-most column for the cell, but in your
examples you're calling that right-aligned (and vice-versa). Along the
lines of what Stefan said, I think this probably came about more as a
"we'll just keep things simple and use the same alignment everywhere"
rather than an intentional right-alignment of text for a specific purpose.
I would actually be fine with left-aligning text to fit what appears to be
standard practice in other systems.

Cheers,

Derek

On Tue, Jan 9, 2024 at 7:34 AM Brad  wrote:

> CQLSH currently left-aligns all output, affecting both numbers and text.
> While this works well for numbers, a better approach adopted by many is to
> left align numbers and right align text.
>
> For example, both Excel and Postgres shell use the later:
>
> psql
>
> # select * from employee;
>
>  empid |  name   |dept
>
> ---+-+
>
>  1 | Clark   | Sales
>
>200 | Dave| Accounting
>
> 33 | Johnson | Sales
>
>
> while CQLSH simply left aligns all the columns
>
> cqlsh> select * from employee;
>
>  empid | dept   | name
>
> ---++-
>
> 33 |  Sales | Johnson
>
>  1 |  Sales |   Clark
>
>200 | Accounting |Dave
>
>
>
> Left aligned text looks much worse on text values which share common
> prefixes
>
>
> cqlsh> select * from system_views.system_properties limit 7 ;
>
>
>  name   | value
>
>
> +
>
>   JAVA_HOME |
>   /Users/brad/.jenv/versions/17
>
>cassandra.jmx.local.port |
>   7199
>
>cassandra.logdir |
> /usr/local/cassandra-5.0-beta1/bin/../logs
>
>cassandra.storagedir |
> /usr/local/cassandra-5.0-beta1/bin/../data
>
>   com.sun.management.jmxremote.authenticate |
> false
>
>  com.sun.management.jmxremote.password.file |
>   /etc/cassandra/jmxremote.password
>
> io.netty.transport.estimateSizeOnSubmit |
> false
>
>
>
> The Jira CASSANDRA-19150
>  discusses this in
> further detail with some additional examples.
>
>
> I wanted to raise the issue here to propose changing CQLSH to right-align
> text while continue to left-align numbers.
>
>
> Regards,
>
>
> Brad Schoening
>
>
> ReplyForward
> Add reaction
>


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Miklosovic, Stefan via dev]

My personal bet is that from the very beginning, Cassandra was more 
"number-centric" and right alignment just made more sense back then, 
considering strings as an afterthought. Another explanation is that nobody 
actually put any work to it to distinguish strings and numbers and it stayed 
like that. I can definitely see the value in left alignment for strings. Whole 
system of written "latin" language is to do it from left to right. Arabic is 
from right to left and there it makes more sense but that is imho absolute 
minority in practice so left alignment just makes more sense to me overall in 
every situation (for strings)


From: Derek Chen-Becker 
Sent: Tuesday, January 9, 2024 17:15
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CQLSH should left-align numbers, right-align text 
(CASSANDRA-19150)

EXTERNAL EMAIL - USE CAUTION when clicking links or attachments



In the ticket itself there's an example of left aligned being better for prefix 
strings (e.g. fully qualified class names), and I suspect this is similarly 
useful for other things like file paths, etc. I would also agree with Stefan 
that it would be nice to know why the current convention was chosen in the 
first place.

Cheers,

Derek

On Tue, Jan 9, 2024 at 8:18 AM Brad 
mailto:bscho...@gmail.com>> wrote:
Derek,

I'm proposing a switch or blanket change to a convention of right aligned text 
and left aligned numbers in CQLSH.

I took a look at two other examples, Excel and Postgres shell and that's how 
they work when displaying tabular data.  The Jira was originally to make right 
or left alignment an option, but making it configurable seems less useful than 
choosing a better standard.

On Tue, Jan 9, 2024 at 9:58 AM Derek Chen-Becker 
mailto:de...@chen-becker.org>> wrote:
Just to clarify, per the ticket you're proposing a configuration option to 
control this on a per-column basis, correct? Your email makes it sound like a 
blanket change.

Cheers,

Derek

On Tue, Jan 9, 2024 at 7:34 AM Brad 
mailto:bscho...@gmail.com>> wrote:
CQLSH currently left-aligns all output, affecting both numbers and text.  While 
this works well for numbers, a better approach adopted by many is to left align 
numbers and right align text.

For example, both Excel and Postgres shell use the later:


psql

# select * from employee;

 empid |  name   |dept

---+-+

 1 | Clark   | Sales

   200 | Dave| Accounting

33 | Johnson | Sales

while CQLSH simply left aligns all the columns


cqlsh> select * from employee;

 empid | dept   | name

---++-

33 |  Sales | Johnson

 1 |  Sales |   Clark

   200 | Accounting |Dave



Left aligned text looks much worse on text values which share common prefixes


cqlsh> select * from system_views.system_properties limit 7 ;


 name   | value

+

  JAVA_HOME |  
/Users/brad/.jenv/versions/17

   cassandra.jmx.local.port |   
7199

   cassandra.logdir | 
/usr/local/cassandra-5.0-beta1/bin/../logs

   cassandra.storagedir | 
/usr/local/cassandra-5.0-beta1/bin/../data

  com.sun.management.jmxremote.authenticate |   
   false

 com.sun.management.jmxremote.password.file |  
/etc/cassandra/jmxremote.password

io.netty.transport.estimateSizeOnSubmit |   
   false



The Jira CASSANDRA-19150 
discusses this in further detail with some additional examples.


I wanted to raise the issue here to propose changing CQLSH to right-align text 
while continue to left-align numbers.


Regards,


Brad Schoening


[https://lh3.googleusercontent.com/a/ACg8ocIyewytSUXGiqiyXhMz6n1Kw3G3R_QAsy09jFQvse8HqQ=s80-p-mo]
ReplyForward

Add reaction


--
+---+
| Derek Chen-Becker |
| GPG Key available at 
https://keybase.io/dchenbecker and   |
| 
https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org
 |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+



--
+---+
| Derek Chen-Becker |
| GPG Key available at 
https://keybase.io/dchenbecker and   |
| 
https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org
 |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Derek Chen-Becker]

In the ticket itself there's an example of left aligned being better for
prefix strings (e.g. fully qualified class names), and I suspect this is
similarly useful for other things like file paths, etc. I would also agree
with Stefan that it would be nice to know why the current convention was
chosen in the first place.

Cheers,

Derek

On Tue, Jan 9, 2024 at 8:18 AM Brad  wrote:

> Derek,
>
> I'm proposing a switch or blanket change to a convention of right aligned
> text and left aligned numbers in CQLSH.
>
> I took a look at two other examples, Excel and Postgres shell and that's
> how they work when displaying tabular data.  The Jira was originally to
> make right or left alignment an option, but making it configurable seems
> less useful than choosing a better standard.
>
> On Tue, Jan 9, 2024 at 9:58 AM Derek Chen-Becker 
> wrote:
>
>> Just to clarify, per the ticket you're proposing a configuration option
>> to control this on a per-column basis, correct? Your email makes it sound
>> like a blanket change.
>>
>> Cheers,
>>
>> Derek
>>
>> On Tue, Jan 9, 2024 at 7:34 AM Brad  wrote:
>>
>>> CQLSH currently left-aligns all output, affecting both numbers and
>>> text.  While this works well for numbers, a better approach adopted by many
>>> is to left align numbers and right align text.
>>>
>>> For example, both Excel and Postgres shell use the later:
>>>
>>> psql
>>>
>>> # select * from employee;
>>>
>>>  empid |  name   |dept
>>>
>>> ---+-+
>>>
>>>  1 | Clark   | Sales
>>>
>>>200 | Dave| Accounting
>>>
>>> 33 | Johnson | Sales
>>>
>>>
>>> while CQLSH simply left aligns all the columns
>>>
>>> cqlsh> select * from employee;
>>>
>>>  empid | dept   | name
>>>
>>> ---++-
>>>
>>> 33 |  Sales | Johnson
>>>
>>>  1 |  Sales |   Clark
>>>
>>>200 | Accounting |Dave
>>>
>>>
>>>
>>> Left aligned text looks much worse on text values which share common
>>> prefixes
>>>
>>>
>>> cqlsh> select * from system_views.system_properties limit 7 ;
>>>
>>>
>>>  name   | value
>>>
>>>
>>> +
>>>
>>>   JAVA_HOME |
>>>   /Users/brad/.jenv/versions/17
>>>
>>>cassandra.jmx.local.port |
>>> 7199
>>>
>>>cassandra.logdir |
>>> /usr/local/cassandra-5.0-beta1/bin/../logs
>>>
>>>cassandra.storagedir |
>>> /usr/local/cassandra-5.0-beta1/bin/../data
>>>
>>>   com.sun.management.jmxremote.authenticate |
>>>   false
>>>
>>>  com.sun.management.jmxremote.password.file |
>>>   /etc/cassandra/jmxremote.password
>>>
>>> io.netty.transport.estimateSizeOnSubmit |
>>>   false
>>>
>>>
>>>
>>> The Jira CASSANDRA-19150
>>>  discusses this
>>> in further detail with some additional examples.
>>>
>>>
>>> I wanted to raise the issue here to propose changing CQLSH to
>>> right-align text while continue to left-align numbers.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Brad Schoening
>>>
>>>
>>> ReplyForward
>>> Add reaction
>>>
>>
>>
>> --
>> +---+
>> | Derek Chen-Becker |
>> | GPG Key available at https://keybase.io/dchenbecker and   |
>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>> +---+
>>
>>

-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Miklosovic, Stefan via dev]

I would like to know whose idea was it to align it like it is currently done in 
the first place. Maybe we are missing something important like why it was done 
like that? If there is no reason, we might just start to align it as other DB 
offerings do. My initial proposal to support both is more about not breaking it 
but if "breaking it" does not make anybody complaining, we can just go without 
dual solution.


From: Brandon Williams 
Sent: Tuesday, January 9, 2024 16:30
To: dev@cassandra.apache.org
Subject: Re: [Discuss] CQLSH should left-align numbers, right-align text 
(CASSANDRA-19150)

EXTERNAL EMAIL - USE CAUTION when clicking links or attachments



A configuration option for a cosmetic feature seems like overkill to me, I 
don't think which side we align text on is enough to justify (heh) the 
overhead.  I agree with how Excel and Postgres do it and think we should follow 
suit.

Kind Regards,
Brandon


On Tue, Jan 9, 2024 at 9:19 AM Brad 
mailto:bscho...@gmail.com>> wrote:
Derek,

I'm proposing a switch or blanket change to a convention of right aligned text 
and left aligned numbers in CQLSH.

I took a look at two other examples, Excel and Postgres shell and that's how 
they work when displaying tabular data.  The Jira was originally to make right 
or left alignment an option, but making it configurable seems less useful than 
choosing a better standard.

On Tue, Jan 9, 2024 at 9:58 AM Derek Chen-Becker 
mailto:de...@chen-becker.org>> wrote:
Just to clarify, per the ticket you're proposing a configuration option to 
control this on a per-column basis, correct? Your email makes it sound like a 
blanket change.

Cheers,

Derek

On Tue, Jan 9, 2024 at 7:34 AM Brad 
mailto:bscho...@gmail.com>> wrote:
CQLSH currently left-aligns all output, affecting both numbers and text.  While 
this works well for numbers, a better approach adopted by many is to left align 
numbers and right align text.

For example, both Excel and Postgres shell use the later:


psql

# select * from employee;

 empid |  name   |dept

---+-+

 1 | Clark   | Sales

   200 | Dave| Accounting

33 | Johnson | Sales

while CQLSH simply left aligns all the columns


cqlsh> select * from employee;

 empid | dept   | name

---++-

33 |  Sales | Johnson

 1 |  Sales |   Clark

   200 | Accounting |Dave



Left aligned text looks much worse on text values which share common prefixes


cqlsh> select * from system_views.system_properties limit 7 ;


 name   | value

+

  JAVA_HOME |  
/Users/brad/.jenv/versions/17

   cassandra.jmx.local.port |   
7199

   cassandra.logdir | 
/usr/local/cassandra-5.0-beta1/bin/../logs

   cassandra.storagedir | 
/usr/local/cassandra-5.0-beta1/bin/../data

  com.sun.management.jmxremote.authenticate |   
   false

 com.sun.management.jmxremote.password.file |  
/etc/cassandra/jmxremote.password

io.netty.transport.estimateSizeOnSubmit |   
   false



The Jira CASSANDRA-19150 
discusses this in further detail with some additional examples.


I wanted to raise the issue here to propose changing CQLSH to right-align text 
while continue to left-align numbers.


Regards,


Brad Schoening


[X]
ReplyForward

Add reaction


--
+---+
| Derek Chen-Becker |
| GPG Key available at 
https://keybase.io/dchenbecker and   |
| 
https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org
 |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Brandon Williams]

A configuration option for a cosmetic feature seems like overkill to me, I
don't think which side we align text on is enough to justify (heh) the
overhead.  I agree with how Excel and Postgres do it and think we should
follow suit.

Kind Regards,
Brandon


On Tue, Jan 9, 2024 at 9:19 AM Brad  wrote:

> Derek,
>
> I'm proposing a switch or blanket change to a convention of right aligned
> text and left aligned numbers in CQLSH.
>
> I took a look at two other examples, Excel and Postgres shell and that's
> how they work when displaying tabular data.  The Jira was originally to
> make right or left alignment an option, but making it configurable seems
> less useful than choosing a better standard.
>
> On Tue, Jan 9, 2024 at 9:58 AM Derek Chen-Becker 
> wrote:
>
>> Just to clarify, per the ticket you're proposing a configuration option
>> to control this on a per-column basis, correct? Your email makes it sound
>> like a blanket change.
>>
>> Cheers,
>>
>> Derek
>>
>> On Tue, Jan 9, 2024 at 7:34 AM Brad  wrote:
>>
>>> CQLSH currently left-aligns all output, affecting both numbers and
>>> text.  While this works well for numbers, a better approach adopted by many
>>> is to left align numbers and right align text.
>>>
>>> For example, both Excel and Postgres shell use the later:
>>>
>>> psql
>>>
>>> # select * from employee;
>>>
>>>  empid |  name   |dept
>>>
>>> ---+-+
>>>
>>>  1 | Clark   | Sales
>>>
>>>200 | Dave| Accounting
>>>
>>> 33 | Johnson | Sales
>>>
>>>
>>> while CQLSH simply left aligns all the columns
>>>
>>> cqlsh> select * from employee;
>>>
>>>  empid | dept   | name
>>>
>>> ---++-
>>>
>>> 33 |  Sales | Johnson
>>>
>>>  1 |  Sales |   Clark
>>>
>>>200 | Accounting |Dave
>>>
>>>
>>>
>>> Left aligned text looks much worse on text values which share common
>>> prefixes
>>>
>>>
>>> cqlsh> select * from system_views.system_properties limit 7 ;
>>>
>>>
>>>  name   | value
>>>
>>>
>>> +
>>>
>>>   JAVA_HOME |
>>>   /Users/brad/.jenv/versions/17
>>>
>>>cassandra.jmx.local.port |
>>> 7199
>>>
>>>cassandra.logdir |
>>> /usr/local/cassandra-5.0-beta1/bin/../logs
>>>
>>>cassandra.storagedir |
>>> /usr/local/cassandra-5.0-beta1/bin/../data
>>>
>>>   com.sun.management.jmxremote.authenticate |
>>>   false
>>>
>>>  com.sun.management.jmxremote.password.file |
>>>   /etc/cassandra/jmxremote.password
>>>
>>> io.netty.transport.estimateSizeOnSubmit |
>>>   false
>>>
>>>
>>>
>>> The Jira CASSANDRA-19150
>>>  discusses this
>>> in further detail with some additional examples.
>>>
>>>
>>> I wanted to raise the issue here to propose changing CQLSH to
>>> right-align text while continue to left-align numbers.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Brad Schoening
>>>
>>>
>>> ReplyForward
>>> Add reaction
>>>
>>
>>
>> --
>> +---+
>> | Derek Chen-Becker |
>> | GPG Key available at https://keybase.io/dchenbecker and   |
>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>> +---+
>>
>>

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Brad]

Derek,

I'm proposing a switch or blanket change to a convention of right aligned
text and left aligned numbers in CQLSH.

I took a look at two other examples, Excel and Postgres shell and that's
how they work when displaying tabular data.  The Jira was originally to
make right or left alignment an option, but making it configurable seems
less useful than choosing a better standard.

On Tue, Jan 9, 2024 at 9:58 AM Derek Chen-Becker 
wrote:

> Just to clarify, per the ticket you're proposing a configuration option to
> control this on a per-column basis, correct? Your email makes it sound like
> a blanket change.
>
> Cheers,
>
> Derek
>
> On Tue, Jan 9, 2024 at 7:34 AM Brad  wrote:
>
>> CQLSH currently left-aligns all output, affecting both numbers and text.
>> While this works well for numbers, a better approach adopted by many is to
>> left align numbers and right align text.
>>
>> For example, both Excel and Postgres shell use the later:
>>
>> psql
>>
>> # select * from employee;
>>
>>  empid |  name   |dept
>>
>> ---+-+
>>
>>  1 | Clark   | Sales
>>
>>200 | Dave| Accounting
>>
>> 33 | Johnson | Sales
>>
>>
>> while CQLSH simply left aligns all the columns
>>
>> cqlsh> select * from employee;
>>
>>  empid | dept   | name
>>
>> ---++-
>>
>> 33 |  Sales | Johnson
>>
>>  1 |  Sales |   Clark
>>
>>200 | Accounting |Dave
>>
>>
>>
>> Left aligned text looks much worse on text values which share common
>> prefixes
>>
>>
>> cqlsh> select * from system_views.system_properties limit 7 ;
>>
>>
>>  name   | value
>>
>>
>> +
>>
>>   JAVA_HOME |
>>   /Users/brad/.jenv/versions/17
>>
>>cassandra.jmx.local.port |
>>   7199
>>
>>cassandra.logdir |
>> /usr/local/cassandra-5.0-beta1/bin/../logs
>>
>>cassandra.storagedir |
>> /usr/local/cassandra-5.0-beta1/bin/../data
>>
>>   com.sun.management.jmxremote.authenticate |
>>   false
>>
>>  com.sun.management.jmxremote.password.file |
>>   /etc/cassandra/jmxremote.password
>>
>> io.netty.transport.estimateSizeOnSubmit |
>>   false
>>
>>
>>
>> The Jira CASSANDRA-19150
>>  discusses this
>> in further detail with some additional examples.
>>
>>
>> I wanted to raise the issue here to propose changing CQLSH to right-align
>> text while continue to left-align numbers.
>>
>>
>> Regards,
>>
>>
>> Brad Schoening
>>
>>
>> ReplyForward
>> Add reaction
>>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>

Re: Welcome Maxim Muzafarov as Cassandra Committer

[Paulo Motta]

Congratulations Maxim!

On Tue, Jan 9, 2024 at 10:16 AM Benjamin Lerer  wrote:

> I am always late to the party. ;-)
>  Congrats Maxim!
>
> Le mar. 9 janv. 2024 à 13:16, Maxim Muzafarov  a
> écrit :
>
>> Thank you all so much, I'm happy to be part of such an active
>> community and to be able to contribute to the product that is used all
>> over the world!
>>
>> On Tue, 9 Jan 2024 at 12:33, Mike Adamson  wrote:
>> >
>> > Congrats Maxim!!
>> >
>> > On Tue, 9 Jan 2024, 10:41 Andrés de la Peña, 
>> wrote:
>> >>
>> >> Congrats, Maxim!
>> >>
>> >> On Tue, 9 Jan 2024 at 03:45, guo Maxwell  wrote:
>> >>>
>> >>> Congratulations, Maxim!
>> >>>
>> >>> Francisco Guerrero  于2024年1月9日周二 09:00写道：
>> 
>>  Congratulations, Maxim! Well deserved!
>> 
>>  On 2024/01/08 18:19:04 Josh McKenzie wrote:
>>  > The Apache Cassandra PMC is pleased to announce that Maxim
>> Muzafarov has accepted
>>  > the invitation to become a committer.
>>  >
>>  > Thanks for all the hard work and collaboration on the project thus
>> far, and we're all looking forward to working more with you in the future.
>> Congratulations and welcome!
>>  >
>>  > The Apache Cassandra PMC members
>>  >
>>  >
>>
>

Re: Welcome Maxim Muzafarov as Cassandra Committer

[Benjamin Lerer]

I am always late to the party. ;-)
 Congrats Maxim!

Le mar. 9 janv. 2024 à 13:16, Maxim Muzafarov  a écrit :

> Thank you all so much, I'm happy to be part of such an active
> community and to be able to contribute to the product that is used all
> over the world!
>
> On Tue, 9 Jan 2024 at 12:33, Mike Adamson  wrote:
> >
> > Congrats Maxim!!
> >
> > On Tue, 9 Jan 2024, 10:41 Andrés de la Peña, 
> wrote:
> >>
> >> Congrats, Maxim!
> >>
> >> On Tue, 9 Jan 2024 at 03:45, guo Maxwell  wrote:
> >>>
> >>> Congratulations, Maxim!
> >>>
> >>> Francisco Guerrero  于2024年1月9日周二 09:00写道：
> 
>  Congratulations, Maxim! Well deserved!
> 
>  On 2024/01/08 18:19:04 Josh McKenzie wrote:
>  > The Apache Cassandra PMC is pleased to announce that Maxim
> Muzafarov has accepted
>  > the invitation to become a committer.
>  >
>  > Thanks for all the hard work and collaboration on the project thus
> far, and we're all looking forward to working more with you in the future.
> Congratulations and welcome!
>  >
>  > The Apache Cassandra PMC members
>  >
>  >
>

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Derek Chen-Becker]

Just to clarify, per the ticket you're proposing a configuration option to
control this on a per-column basis, correct? Your email makes it sound like
a blanket change.

Cheers,

Derek

On Tue, Jan 9, 2024 at 7:34 AM Brad  wrote:

> CQLSH currently left-aligns all output, affecting both numbers and text.
> While this works well for numbers, a better approach adopted by many is to
> left align numbers and right align text.
>
> For example, both Excel and Postgres shell use the later:
>
> psql
>
> # select * from employee;
>
>  empid |  name   |dept
>
> ---+-+
>
>  1 | Clark   | Sales
>
>200 | Dave| Accounting
>
> 33 | Johnson | Sales
>
>
> while CQLSH simply left aligns all the columns
>
> cqlsh> select * from employee;
>
>  empid | dept   | name
>
> ---++-
>
> 33 |  Sales | Johnson
>
>  1 |  Sales |   Clark
>
>200 | Accounting |Dave
>
>
>
> Left aligned text looks much worse on text values which share common
> prefixes
>
>
> cqlsh> select * from system_views.system_properties limit 7 ;
>
>
>  name   | value
>
>
> +
>
>   JAVA_HOME |
>   /Users/brad/.jenv/versions/17
>
>cassandra.jmx.local.port |
>   7199
>
>cassandra.logdir |
> /usr/local/cassandra-5.0-beta1/bin/../logs
>
>cassandra.storagedir |
> /usr/local/cassandra-5.0-beta1/bin/../data
>
>   com.sun.management.jmxremote.authenticate |
> false
>
>  com.sun.management.jmxremote.password.file |
>   /etc/cassandra/jmxremote.password
>
> io.netty.transport.estimateSizeOnSubmit |
> false
>
>
>
> The Jira CASSANDRA-19150
>  discusses this in
> further detail with some additional examples.
>
>
> I wanted to raise the issue here to propose changing CQLSH to right-align
> text while continue to left-align numbers.
>
>
> Regards,
>
>
> Brad Schoening
>
>
> ReplyForward
> Add reaction
>


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

[Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Brad]

CQLSH currently left-aligns all output, affecting both numbers and text.
While this works well for numbers, a better approach adopted by many is to
left align numbers and right align text.

For example, both Excel and Postgres shell use the later:

psql

# select * from employee;

 empid |  name   |dept

---+-+

 1 | Clark   | Sales

   200 | Dave| Accounting

33 | Johnson | Sales


while CQLSH simply left aligns all the columns

cqlsh> select * from employee;

 empid | dept   | name

---++-

33 |  Sales | Johnson

 1 |  Sales |   Clark

   200 | Accounting |Dave



Left aligned text looks much worse on text values which share common
prefixes


cqlsh> select * from system_views.system_properties limit 7 ;


 name   | value

+

  JAVA_HOME |
  /Users/brad/.jenv/versions/17

   cassandra.jmx.local.port |
7199

   cassandra.logdir |
/usr/local/cassandra-5.0-beta1/bin/../logs

   cassandra.storagedir |
/usr/local/cassandra-5.0-beta1/bin/../data

  com.sun.management.jmxremote.authenticate |
false

 com.sun.management.jmxremote.password.file |
  /etc/cassandra/jmxremote.password

io.netty.transport.estimateSizeOnSubmit |
false



The Jira CASSANDRA-19150
 discusses this in
further detail with some additional examples.


I wanted to raise the issue here to propose changing CQLSH to right-align
text while continue to left-align numbers.


Regards,


Brad Schoening


ReplyForward
Add reaction

Re: Welcome Maxim Muzafarov as Cassandra Committer

[Maxim Muzafarov]

Thank you all so much, I'm happy to be part of such an active
community and to be able to contribute to the product that is used all
over the world!

On Tue, 9 Jan 2024 at 12:33, Mike Adamson  wrote:
>
> Congrats Maxim!!
>
> On Tue, 9 Jan 2024, 10:41 Andrés de la Peña,  wrote:
>>
>> Congrats, Maxim!
>>
>> On Tue, 9 Jan 2024 at 03:45, guo Maxwell  wrote:
>>>
>>> Congratulations, Maxim!
>>>
>>> Francisco Guerrero  于2024年1月9日周二 09:00写道：

 Congratulations, Maxim! Well deserved!

 On 2024/01/08 18:19:04 Josh McKenzie wrote:
 > The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov has 
 > accepted
 > the invitation to become a committer.
 >
 > Thanks for all the hard work and collaboration on the project thus far, 
 > and we're all looking forward to working more with you in the future. 
 > Congratulations and welcome!
 >
 > The Apache Cassandra PMC members
 >
 >

Re: Call for Presentations closing soon: Community over Code EU 2024

[Claude Warren, Jr via dev]

Additionally, if you have a talk about some underlying technology that
could be applicable across multiple projects submit it or a poster based on
it.  We are looking for good cross-project presentations.

Claude
Chair, Community over Code, EU 2024.

On Mon, Jan 8, 2024 at 8:24 PM Paulo Motta  wrote:

> I wanted to remind that the call for speakers for Community Over Code EU
> 2024 (formerly Apachecon EU) will be closing this Friday 2024/01/12
> 23:59:59 GMT.
>
> If you reside in Europe/EMEA and have an interesting talk proposal about
> using, deploying or modifying Apache Cassandra please see details below to
> submit a proposal to this conference.
>
> -- Forwarded message -
> From: Ryan Skraba 
> Date: Mon, Oct 30, 2023 at 1:07 PM
> Subject: Call for Presentations now open: Community over Code EU 2024
> To:
>
>
> (Note: You are receiving this because you are subscribed to the dev@
> list for one or more projects of the Apache Software Foundation.)
>
> It's back *and* it's new!
>
> We're excited to announce that the first edition of Community over
> Code Europe (formerly known as ApacheCon EU) which will be held at the
> Radisson Blu Carlton Hotel in Bratislava, Slovakia from June 03-05,
> 2024! This eagerly anticipated event will be our first live EU
> conference since 2019.
>
> The Call for Presentations (CFP) for Community Over Code EU 2024 is
> now open at https://eu.communityovercode.org/blog/cfp-open/,
> and will close 2024/01/12 23:59:59 GMT.
>
> We welcome submissions on any topic related to the Apache Software
> Foundation, Apache projects, or the communities around those projects.
> We are specifically looking for presentations in the following
> categories:
>
> * API & Microservices
> * Big Data Compute
> * Big Data Storage
> * Cassandra
> * CloudStack
> * Community
> * Data Engineering
> * Fintech
> * Groovy
> * Incubator
> * IoT
> * Performance Engineering
> * Search
> * Tomcat, Httpd and other servers
>
> Additionally, we are thrilled to introduce a new feature this year: a
> poster session. This addition will provide an excellent platform for
> showcasing high-level projects and incubator initiatives in a visually
> engaging manner. We believe this will foster lively discussions and
> facilitate networking opportunities among participants.
>
> All my best, and thanks so much for your participation,
>
> Ryan Skraba (on behalf of the program committee)
>
> [Countdown]:
> https://www.timeanddate.com/countdown/to?iso=20240112T2359=1440
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Welcome Maxim Muzafarov as Cassandra Committer

[Mike Adamson]

Congrats Maxim!!

On Tue, 9 Jan 2024, 10:41 Andrés de la Peña,  wrote:

> Congrats, Maxim!
>
> On Tue, 9 Jan 2024 at 03:45, guo Maxwell  wrote:
>
>> Congratulations, Maxim!
>>
>> Francisco Guerrero  于2024年1月9日周二 09:00写道：
>>
>>> Congratulations, Maxim! Well deserved!
>>>
>>> On 2024/01/08 18:19:04 Josh McKenzie wrote:
>>> > The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov
>>> has accepted
>>> > the invitation to become a committer.
>>> >
>>> > Thanks for all the hard work and collaboration on the project thus
>>> far, and we're all looking forward to working more with you in the future.
>>> Congratulations and welcome!
>>> >
>>> > The Apache Cassandra PMC members
>>> >
>>> >
>>>
>>

Re: [DISCUSSION] CEP-38: CQL Management API

[Maxim Muzafarov]

Jon,

That sounds good.  Let's make these commands rely on the settings
virtual table and keep the initial changes as minimal as possible.

We've also scheduled a Cassandra Contributor Meeting on January 30th
2024, so I'll prepare some slides with everything we've got so far and
try to prepare some drafts to demonstrate the design.
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Contributor+Meeting

On Tue, 9 Jan 2024 at 00:55, Jon Haddad  wrote:
>
> It's great to see where this is going and thanks for the discussion on the ML.
>
> Personally, I think adding two new ways of accomplishing the same thing is a 
> net negative.  It 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 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 couple hundred teams and I can only think of a few who use 
> JMX directly.  It's done very rarely.  After 10 years, I still have to look 
> up the JMX syntax to do anything useful, especially if there's any quoting 
> involved.  Power users might know a handful of JMX commands by heart, but I 
> suspect most have a handful of bash scripts they use instead, or have a 
> sidecar.  I also think very few users will migrate their management code from 
> JMX to CQL, nor do I imagine we'll move our own tools until the 
> `disablebinary` problem is solved.
>
> > - It will be easier for us to move the nodetool from the jmx client that is 
> > used under the hood to an implementation based on a java-driver and use the 
> > CQL for the same;
>
> I can't imagine this would make a material difference.  If someone's 
> rewriting a nodetool command, how much time will be spent replacing the JMX 
> call with a CQL one?  Looking up a virtual table isn't going to be what 
> consumes someone's time in this process.  Again, this won't be done without 
> solving `nodetool disablebinary`.
>
> > if we have cassandra-15254 merged, it will cost almost nothing to support 
> > the exec syntax for setting properties;
>
> My concern is more about the weird user experience of having two ways of 
> doing the same thing, less about the technical overhead of adding a second 
> implementation.  I propose we start simple, see if any of the reasons you've 
> listed are actually a real problem, then if they are, address the issue in a 
> follow up.
>
> If I'm wrong, it sounds like it's fairly easy to add `exec` for changing 
> configs.  If I'm right, we'll have two confusing syntaxes forever.  It's a 
> lot easier to add something later than take it away.
>
> How does that sound?
>
> Jon
>
>
>
>
> On Mon, Jan 8, 2024 at 7:55 PM Maxim Muzafarov  wrote:
>>
>> > Some operations will no doubt require a stored procedure syntax, but 
>> > perhaps it would be a good idea to split the work into two:
>>
>> These are exactly the first steps I have in mind:
>>
>> [Ready for review]
>> Allow UPDATE on settings virtual table to change running configurations
>> https://issues.apache.org/jira/browse/CASSANDRA-15254
>>
>> This issue is specifically aimed at changing the configuration
>> properties we are talking about (value is in yaml format):
>> e.g. UPDATE system_views.settings SET compaction_throughput = 128Mb/s;
>>
>> [Ready for review]
>> Expose all table metrics in virtual table
>> 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 topic, I'd
>> like to discuss the design of the CQL API, and gather feedback, so
>> that I can prepare a draft of changes to look at without any
>> surprises, and that's exactly what this discussion is about.
>>
>>
>> cqlsh> UPDATE system.settings SET compaction_throughput = 128;
>> cqlsh> exec setcompactionthroughput 128
>>
>> I don't mind removing the exec command from the CQL command API which
>> is intended to change settings. Personally, I see the second option as
>> just an alias for the first command, and in fact, they will have the
>> same implementation under the hood, so please consider the rationale
>> below:
>>
>> - 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;
>> - It will be easier for us to move the nodetool from the jmx client
>> that is used under the hood to an implementation based on a
>> java-driver and use the CQL for the same;
>> - if we have cassandra-15254 merged, it will cost almost nothing to
>> support the exec syntax 

Re: Welcome Maxim Muzafarov as Cassandra Committer

[Andrés de la Peña]

Congrats, Maxim!

On Tue, 9 Jan 2024 at 03:45, guo Maxwell  wrote:

> Congratulations, Maxim!
>
> Francisco Guerrero  于2024年1月9日周二 09:00写道：
>
>> Congratulations, Maxim! Well deserved!
>>
>> On 2024/01/08 18:19:04 Josh McKenzie wrote:
>> > The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov
>> has accepted
>> > the invitation to become a committer.
>> >
>> > Thanks for all the hard work and collaboration on the project thus far,
>> and we're all looking forward to working more with you in the future.
>> Congratulations and welcome!
>> >
>> > The Apache Cassandra PMC members
>> >
>> >
>>
>