Re: A proposal for refactoring the CircleCI config

[Claude Warren, Jr via dev]

I have been working on
https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-18012
which modifies the generate.sh script for the circleci configurations.
Perhaps all of this should be rolled into one change?

On Fri, Nov 11, 2022 at 3:47 AM Ekaterina Dimitrova 
wrote:

> 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.
> Thanks,
> Ekaterina
>
> On Wed, 2 Nov 2022 at 17:08, David Capwell  wrote:
>
>> Here is the ticket I was talking about
>> https://issues.apache.org/jira/browse/CASSANDRA-17600
>>
>>
>> On Nov 2, 2022, at 1:29 PM, Derek Chen-Becker 
>> wrote:
>>
>> For the parallel param logic, sounds fine to me.  Not sure if this would
>> also work for resource_type, but I still argue that xlarge isn’t needed in
>> 90% of the cases its used… so fixing this may be better than param there….
>> So yes, I would be cool with this change if it basically removes the
>> patching logic… I had another JIRA to have a python script rewrite the
>> YAML, but this method may solve in a cleaner way.
>>
>>
>> Almost any part of a CircleCI definition can be replaced with a
>> parameter, so basically we want config-2_1.yml to be a template, and
>> we plug different values in as desired. Would you mind sending a link
>> to that JIRA so I can understand that use case?
>>
>> About matrix jobs; I don’t know them in circle but have used in other
>> places, this sounds good to me.  I would also enhance to argue that JVM is
>> just 1 config and we sadly have many more:
>>
>> JVM: [8, 11, 17]
>> VNODE: [true, false]
>> CDC: [true, false]
>> COMPRESSION: [true, false]
>> MEMTABLE: [skiplist, shardedskiplist, trie]
>>
>>
>> My understanding is that we could parameterize all of these such that
>> we could use a matrix as long as all combinations are valid. Let me
>> get parameterization of basic configuration reviewed first, and then
>> we can take a look at how to matricize things.
>>
>> Cheers,
>>
>> Derek
>>
>> --
>> +---+
>> | 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: Naming conventions for CQL native functions

[Andrés de la Peña]

Thanks for the feedback. Adopting snake case and using aliases seems pretty
uncontroversial so far. I have created CASSANDRA-18037
 for doing it.

On Thu, 10 Nov 2022 at 19:06, Jeremy Hanna 
wrote:

> +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
> >> 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, 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.
> >
> > 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 "castAsInt" or
> > "castAsTimestamp". Note that the came cased names require quoting
> due to
> > CQL's case insensitivity.
> >
> > Differently to CQL native functions, system keyspaces, tables and
> > columns consistently use snake case. For example, we have
> "system_schema",
> > "dropped_columns", "default_time_to_live".
> >
> > I think it would be good to adopt a convention on how to name CQL
> native
> > functions, at least the new ones. 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.
> >
> > For example, in CASSANDRA-17811 I'm working on a set of functions to
> do
> > within-collection operations, which would be named "map_keys",
> > "map_values", "collection_min", "collection_max", "collection_sum",
> > "collection_count", etc. Also, CEP-20 will add a set of functions
> that
> > would be named "mask_null", "mask_default", "mask_replace",
> "mask_inner",
> > "mask_outer", "mask_hash", etc.
> >
> > As for the already existing functions, we could either let them be or
> > add snake case aliases for them, so for example we'd have both
> "castAsInt"
> > and "cast_as_int", at least for a time.
> >
> > What do you think?
> >
> 
> >>
>