Hey Derek,
Thanks for looking into this.
As we spoke in Slack, probably an easy way to show people how things will
look like is to have a prototype with some minimal config. Could be even
not Cassandra one but something that will show how things will look like
and improve the current model.
Hi all,
Thank you for your feedback.
Just wanted to address Josh’s two questions from the PR:
1) the dependency section was copy-paste from the agreed some time ago doc.
I am open to remove it, I assumed (maybe I was wrong) that it was missed
while transferring the doc to the web page.
2) we
+1 to switching to G1 as well. Most production clusters I've seen are
typically running with a heap size of 16 GB or higher which works well with
G1.
I agree with Elliott's comment; I think this change should go into 4.1
onwards (i.e. no change to the default JVM settings in 4.0).
On Fri, 11 Nov
Hi everyone,
For the Grace Hopper Open Source Day mentoring hackathon [1] on Sept. 16 I
created a short guide to handout to participants interested in contributing
to Cassandra so they could get quickly get started working on LHF tickets.
There were about 5 participants and most of them were able
>
> In case of GC, reasonably extensive performance testing should be the
> expectations. Potentially revisiting some of the G1 params for the 4.1
> reality - quite a lot has changed since those optional defaults where
> picked.
>
I've put our battle-tested g1 opts (from consultants at TLP and
This seems fraught with peril. I think that it should be fixed, but I
also wonder what the testing requirements would be to validate no
regression. It probably has to be done on a case-by-case basis. Is it
as simple as auditing places where we're calling getBytes or
PrintReader/PrintWriter
+1 (nb) mixed case is a miserable experience and snake case makes it readable.
> On Nov 10, 2022, at 10:57 AM, Francisco Guerrero wrote:
>
> +1 (nb) as well
>
>> On 2022/11/10 17:16:21 Caleb Rackliffe wrote:
>> +100 on snake case for built-in functions given I think MySQL and Postgres
>>
+1 (nb) as well
On 2022/11/10 17:16:21 Caleb Rackliffe wrote:
> +100 on snake case for built-in functions given I think MySQL and Postgres
> use that convention as well.
>
> ex. https://www.postgresql.org/docs/9.2/functions-string.html
>
> On Thu, Nov 10, 2022 at 7:51 AM Brandon Williams
+100 on snake case for built-in functions given I think MySQL and Postgres
use that convention as well.
ex. https://www.postgresql.org/docs/9.2/functions-string.html
On Thu, Nov 10, 2022 at 7:51 AM Brandon Williams wrote:
> I too meant snake case and need coffee.
>
> On Thu, Nov 10, 2022,
I'll withdraw my comment about friendliness of g1 vs cms. I think it's too
late to sneak it in, but wouldn't object formally.
offheap_objects is way too late to change given we shipped the alpha in May
and there are known, long lived bugs that multiple users have reported and
wouldn't have been
+1 to switching to G1.
No opinion about offheap objects.
On 2022/11/09 19:22:08 Mick Semb Wever wrote:
> Any objections to making these changes, at the very last minute, for
> 4.1-rc1 ?
> This is CASSANDRA-12029 and CASSANDRA-7486
>
> Provided we figure out patches for them in the next day
I assume not with 4.0/4.1 though.
It might be a better default than CMS, but switching a major default like this
(an memtable allocation) is not something that should be snuck in at the very
last moment.
In case of GC, reasonably extensive performance testing should be the
expectations.
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 name CQL native
>> functions.
>>
Oh, I meant snake, yes. I need a coffee
На четвъртък, 10 ноември 2022 г. Andrés de la Peña
написа:
> IMO camel case would make sense because it plays well with CQL's case
>> insensitivity, it makes long names easier to read and it's consistent with
>> the names used for most other things.
>
>
>
> IMO camel case would make sense because it plays well with CQL's case
> insensitivity, it makes long names easier to read and it's consistent with
> the names used for most other things.
I meant that we should use snake case, as in "collection_max" and the other
example I give, but I wrongly
+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 separate words. That's
+1 from me too on camel case and the aliases for compatibility
On Thu, 10 Nov 2022 at 7:47, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> Adding snake case aliases for existing functions which are in camel case
> for compatibility and stick to snake case from now on seems to be
Adding snake case aliases for existing functions which are in camel case for
compatibility and stick to snake case from now on 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
+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 functions
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 functions using camel case, as in
+1 to treating as new unvetted tests.
Kind Regards,
Brandon
On Thu, Nov 10, 2022 at 5:41 AM Mick Semb Wever wrote:
>
>
>
> On Thu, 10 Nov 2022 at 10:18, Miklosovic, Stefan
> wrote:
>>
>> I want to ask if people are comfortable with merging CASSANDRA-17964 before
>> 4.1 is out. We clean a lot
On Thu, 10 Nov 2022 at 10:18, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> I want to ask if people are comfortable with merging CASSANDRA-17964
> before 4.1 is out. We clean a lot of things and rename tests which we
> should take care of. (like PaxosRepairTest2).
>
> We might
I want to ask if people are comfortable with merging CASSANDRA-17964 before 4.1
is out. We clean a lot of things and rename tests which we should take care of.
(like PaxosRepairTest2).
We might still fix it without merging 17964 as we know what should be fixed and
we can wait until 4.1 is out
23 matches
Mail list logo
