Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Miklosovic, Stefan]

This is the draft for FILTERING ON|OFF in shell.

I would say this is the most simple solution.

We may still consider table option but what do you think about having it simply 
just set via shell?

https://github.com/apache/cassandra/pull/2141/files


From: Josh McKenzie 
Sent: Friday, February 3, 2023 23:39
To: dev
Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables

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.



they would start to set ALLOW FILTERING here and there in order to not think 
twice about their data model so they can just call it a day.
Setting this on a per-table basis or having users set this on specific queries 
that hit tables and forgetting they set it are 6 of one and half-a-dozen of 
another.

I like the table property idea personally. That communicates an intent about 
the data model and expectation of the size and usage of data in the modeling of 
the schema that embeds some context and intent there's currently no mechanism 
to communicate.

On Fri, Feb 3, 2023, at 5:00 PM, Miklosovic, Stefan wrote:
Yes, there would be discrepancy. I do not like that either. If it was only 
about "normal tables vs virtual tables", I could live with that. But the fact 
that there are going to be differences among vtables themselves, that starts to 
be a little bit messy. Then we would need to let operators know what tables are 
always allowed to be filtered on and which do not and that just complicates it. 
Putting that information to comment so it is visible in DECSCRIBE is nice idea.

That flag we talk about ... that flag would be used purely internally, it would 
not be in schema to be gossiped.

Also, I am starting to like the suggestion to have something like ALLOW 
FILTERING ON in CQLSH so it would be turned on whole CQL session. That leaves 
tables as they are and it should not be a big deal for operators to set. We 
would have to make sure to add "ALLOW FILTERING" clause to every SELECT 
statement (to virtual tables only?) a user submits. I am not sure if this is 
doable yet though.


From: David Capwell mailto:dcapw...@apple.com>>
Sent: Friday, February 3, 2023 22:42
To: dev
Cc: Maxim Muzafarov
Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables

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.



I don't think the assumption that "virtual tables will always be small and 
always fit in memory" is a safe one.

Agree, there is a repair ticket to have the coordinating node do network 
queries to peers to resolve the table (rather than operator querying 
everything, allow the coordinator node to do it for you)… so this assumption 
may not be true down the line.

I could be open to a table property that says ALLOW FILTERING on by default or 
not… then we can pick and choose vtables (or have vtables opt-out)…. I kinda 
like like the lack of consistency with this approach though

On Feb 3, 2023, at 11:24 AM, C. Scott Andreas 
mailto:sc...@paradoxica.net>> wrote:

There are some ideas that development community members have kicked around that 
may falsify the assumption that "virtual tables are tiny and will fit in 
memory."

One example is CASSANDRA-14629: Abstract Virtual Table for very large result 
sets
https://issues.apache.org/jira/browse/CASSANDRA-14629

Chris's proposal here is to enable query results from virtual tables to be 
streamed to the client rather than being fully materialized. There are some 
neat possibilities suggested in this ticket, such as debug functionality to 
dump the contents of a raw SSTable via the CQL interface, or the contents of 
the database's internal caches. One could also imagine a feature like this 
providing functionality similar to a foreign data wrapper in other databases.

I don't think the assumption that "virtual tables will always be small and 
always fit in memory" is a safe one.

I don't think we should implicitly add "ALLOW FILTERING" to all queries against 
virtual tables because of this, in addition to concern with departing from 
standard CQL semantics for a type of tables deemed special.

– Scott

On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov 
mailto:mmu...@apache.org>> wrote:


Hello Stefan,

Regarding the decision to implicitly enable ALLOW FILTERING for
virtual tables, which also makes sense to me, it may be necessary to
consider changing the clustering columns in the virtual table metadata
to regular columns as well. The reasons are the same as mentioned
earlier: the virtual tables hold their data in memory, thus we do not
benefit from the advantages of ordered data (e.g. the ClientsTable and
its ClusteringColumn(PORT)).

Changing the clustering column to a regular column may simplify the
virtual table data model, but I'm 

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Josh McKenzie]

> they would start to set ALLOW FILTERING here and there in order to not think 
> twice about their data model so they can just call it a day.
Setting this on a per-table basis or having users set this on specific queries 
that hit tables and forgetting they set it are 6 of one and half-a-dozen of 
another.

I like the table property idea personally. That communicates an intent about 
the data model and expectation of the size and usage of data in the modeling of 
the schema that embeds some context and intent there's currently no mechanism 
to communicate.

On Fri, Feb 3, 2023, at 5:00 PM, Miklosovic, Stefan wrote:
> Yes, there would be discrepancy. I do not like that either. If it was only 
> about "normal tables vs virtual tables", I could live with that. But the fact 
> that there are going to be differences among vtables themselves, that starts 
> to be a little bit messy. Then we would need to let operators know what 
> tables are always allowed to be filtered on and which do not and that just 
> complicates it. Putting that information to comment so it is visible in 
> DECSCRIBE is nice idea.
> 
> That flag we talk about ... that flag would be used purely internally, it 
> would not be in schema to be gossiped.
> 
> Also, I am starting to like the suggestion to have something like ALLOW 
> FILTERING ON in CQLSH so it would be turned on whole CQL session. That leaves 
> tables as they are and it should not be a big deal for operators to set. We 
> would have to make sure to add "ALLOW FILTERING" clause to every SELECT 
> statement (to virtual tables only?) a user submits. I am not sure if this is 
> doable yet though.
> 
> 
> From: David Capwell 
> Sent: Friday, February 3, 2023 22:42
> To: dev
> Cc: Maxim Muzafarov
> Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables
> 
> 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.
> 
> 
> 
> I don't think the assumption that "virtual tables will always be small and 
> always fit in memory" is a safe one.
> 
> Agree, there is a repair ticket to have the coordinating node do network 
> queries to peers to resolve the table (rather than operator querying 
> everything, allow the coordinator node to do it for you)… so this assumption 
> may not be true down the line.
> 
> I could be open to a table property that says ALLOW FILTERING on by default 
> or not… then we can pick and choose vtables (or have vtables opt-out)…. I 
> kinda like like the lack of consistency with this approach though
> 
> On Feb 3, 2023, at 11:24 AM, C. Scott Andreas  wrote:
> 
> There are some ideas that development community members have kicked around 
> that may falsify the assumption that "virtual tables are tiny and will fit in 
> memory."
> 
> One example is CASSANDRA-14629: Abstract Virtual Table for very large result 
> sets
> https://issues.apache.org/jira/browse/CASSANDRA-14629
> 
> Chris's proposal here is to enable query results from virtual tables to be 
> streamed to the client rather than being fully materialized. There are some 
> neat possibilities suggested in this ticket, such as debug functionality to 
> dump the contents of a raw SSTable via the CQL interface, or the contents of 
> the database's internal caches. One could also imagine a feature like this 
> providing functionality similar to a foreign data wrapper in other databases.
> 
> I don't think the assumption that "virtual tables will always be small and 
> always fit in memory" is a safe one.
> 
> I don't think we should implicitly add "ALLOW FILTERING" to all queries 
> against virtual tables because of this, in addition to concern with departing 
> from standard CQL semantics for a type of tables deemed special.
> 
> – Scott
> 
> On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:
> 
> 
> Hello Stefan,
> 
> Regarding the decision to implicitly enable ALLOW FILTERING for
> virtual tables, which also makes sense to me, it may be necessary to
> consider changing the clustering columns in the virtual table metadata
> to regular columns as well. The reasons are the same as mentioned
> earlier: the virtual tables hold their data in memory, thus we do not
> benefit from the advantages of ordered data (e.g. the ClientsTable and
> its ClusteringColumn(PORT)).
> 
> Changing the clustering column to a regular column may simplify the
> virtual table data model, but I'm afraid it may affect users who rely
> on the table metadata.
> 
> 
> 
> On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña  wrote:
> 
> I think removing the need for ALLOW FILTERING on virtual tables makes sense 
> and would be quite useful for operators.
> 
> That guard exists for performance issues that shouldn't occur on virtual 
> tables. We also have a flag in case some future virtual table implementation 
> has limitations regarding filtering, although it seems it's not the case with 
> any of 

Re: Important news about Cassandra Summit

[Wei Deng]

Thank you for the update, Patrick. Appreciate all the work your team, the
community and the Linux Foundation Events team have done. Looking forward
to the virtual event and Cassandra Day series.

> If you have open positions, call them out in this email thread or
#cassandra in the ASF slack.

Speaking about open positions, our team at DataStax is looking for a senior
software engineer to work on the open source CQL drivers. The detailed job
description can be found here: https://smrtr.io/cFnJS

Folks can apply using the "I'm Interested" link inside the webpage
mentioned above. Feel free to connect with me on LinkedIn (
https://www.linkedin.com/in/weideng/) if this role looks interesting, and
you want to know more about it.

-Wei

On Fri, Feb 3, 2023 at 2:31 PM Patrick McFadin  wrote:

>
>
>
>
>
>
> *Hello Cassandra Community,We all see what’s happening in tech right now.
> Cuts are being made, and budgets are frozen. For Cassandra Summit, this has
> translated to low sponsorship and registrations. The program committee has
> been discussing options with the Linux Foundation events team, and the
> decision was made to move Cassandra Summit to December 12-13. You’ll see
> something official from the Linux Foundation soon. This isn’t what anyone
> wanted. It’s a challenging time for our community to gather, and that’s
> entirely the point of a Cassandra Summit. Hopefully, this provides enough
> space to have the Summit we want and need. Between now and December, the
> DataStax community team is ramping up a plan B to keep up the project
> momentum during this downturn and facilitate community information sharing.
> Cassandra 5.0 is coming, and it’s going to be game-changing. No way we are
> waiting until December to talk about it! The plan is to have a virtual
> event (online) on March 14 and a series of city-specific Cassandra Days in
> the coming months. It’s hard for our community to get out, so we’ll come to
> you. More information will follow in the next few days. I want to reassure
> you this isn’t specific to our community. I’ve been hearing from many that
> you were trying anything to get to San Jose in March, but budgets wouldn’t
> allow for any non-essential travel. When I started hearing the same thing
> from speakers, then sponsors, I knew this was a large-scale problem. We all
> know people impacted by layoffs, and I’m sure many are personally affected.
> Let’s come together as a community and help each other. If you have open
> positions, call them out in this email thread or #cassandra in the ASF
> slack.I want to thank the Linux Foundation Events team personally. They are
> exceptional professionals and worked quickly to get us back on track. There
> was a rush of events trying to postpone to later in the year, but they were
> able to get us a new date. They are as protective of conference uptime like
> you are about database uptime. More info to follow. ThanksPatrick*
>

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Miklosovic, Stefan]

Yes, there would be discrepancy. I do not like that either. If it was only 
about "normal tables vs virtual tables", I could live with that. But the fact 
that there are going to be differences among vtables themselves, that starts to 
be a little bit messy. Then we would need to let operators know what tables are 
always allowed to be filtered on and which do not and that just complicates it. 
Putting that information to comment so it is visible in DECSCRIBE is nice idea.

That flag we talk about ... that flag would be used purely internally, it would 
not be in schema to be gossiped.

Also, I am starting to like the suggestion to have something like ALLOW 
FILTERING ON in CQLSH so it would be turned on whole CQL session. That leaves 
tables as they are and it should not be a big deal for operators to set. We 
would have to make sure to add "ALLOW FILTERING" clause to every SELECT 
statement (to virtual tables only?) a user submits. I am not sure if this is 
doable yet though.


From: David Capwell 
Sent: Friday, February 3, 2023 22:42
To: dev
Cc: Maxim Muzafarov
Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables

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.



I don't think the assumption that "virtual tables will always be small and 
always fit in memory" is a safe one.

Agree, there is a repair ticket to have the coordinating node do network 
queries to peers to resolve the table (rather than operator querying 
everything, allow the coordinator node to do it for you)… so this assumption 
may not be true down the line.

I could be open to a table property that says ALLOW FILTERING on by default or 
not… then we can pick and choose vtables (or have vtables opt-out)…. I kinda 
like like the lack of consistency with this approach though

On Feb 3, 2023, at 11:24 AM, C. Scott Andreas  wrote:

There are some ideas that development community members have kicked around that 
may falsify the assumption that "virtual tables are tiny and will fit in 
memory."

One example is CASSANDRA-14629: Abstract Virtual Table for very large result 
sets
https://issues.apache.org/jira/browse/CASSANDRA-14629

Chris's proposal here is to enable query results from virtual tables to be 
streamed to the client rather than being fully materialized. There are some 
neat possibilities suggested in this ticket, such as debug functionality to 
dump the contents of a raw SSTable via the CQL interface, or the contents of 
the database's internal caches. One could also imagine a feature like this 
providing functionality similar to a foreign data wrapper in other databases.

I don't think the assumption that "virtual tables will always be small and 
always fit in memory" is a safe one.

I don't think we should implicitly add "ALLOW FILTERING" to all queries against 
virtual tables because of this, in addition to concern with departing from 
standard CQL semantics for a type of tables deemed special.

– Scott

On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:


Hello Stefan,

Regarding the decision to implicitly enable ALLOW FILTERING for
virtual tables, which also makes sense to me, it may be necessary to
consider changing the clustering columns in the virtual table metadata
to regular columns as well. The reasons are the same as mentioned
earlier: the virtual tables hold their data in memory, thus we do not
benefit from the advantages of ordered data (e.g. the ClientsTable and
its ClusteringColumn(PORT)).

Changing the clustering column to a regular column may simplify the
virtual table data model, but I'm afraid it may affect users who rely
on the table metadata.



On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña  wrote:

I think removing the need for ALLOW FILTERING on virtual tables makes sense and 
would be quite useful for operators.

That guard exists for performance issues that shouldn't occur on virtual 
tables. We also have a flag in case some future virtual table implementation 
has limitations regarding filtering, although it seems it's not the case with 
any of the existing virtual tables.

It is not like we would promote bad habits because virtual tables are meant to 
be queried by operators / administrators only.


It might even be quite the opposite, since in the current situation users might 
get used to routinely use ALLOW FILTERING for querying their virtual tables.

It has been mentioned on the #cassandra-dev Slack thread where this started (1) 
that it's kind of an API inconsistency to allow querying by non-primary keys on 
virtual tables without ALLOW FILTERING, whereas it's required for regular 
tables. I think that a simply doc update saying that virtual tables, which are 
not regular tables, support filtering would be enough. Virtual tables are well 
identified by both the keyspace they belong to and doc, so users shouldn't have 
trouble knowing 

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[David Capwell]

> I don't think the assumption that "virtual tables will always be small and 
> always fit in memory" is a safe one.

Agree, there is a repair ticket to have the coordinating node do network 
queries to peers to resolve the table (rather than operator querying 
everything, allow the coordinator node to do it for you)… so this assumption 
may not be true down the line.

I could be open to a table property that says ALLOW FILTERING on by default or 
not… then we can pick and choose vtables (or have vtables opt-out)…. I kinda 
like like the lack of consistency with this approach though

> On Feb 3, 2023, at 11:24 AM, C. Scott Andreas  wrote:
> 
> There are some ideas that development community members have kicked around 
> that may falsify the assumption that "virtual tables are tiny and will fit in 
> memory."
> 
> One example is CASSANDRA-14629: Abstract Virtual Table for very large result 
> sets
> https://issues.apache.org/jira/browse/CASSANDRA-14629
> 
> Chris's proposal here is to enable query results from virtual tables to be 
> streamed to the client rather than being fully materialized. There are some 
> neat possibilities suggested in this ticket, such as debug functionality to 
> dump the contents of a raw SSTable via the CQL interface, or the contents of 
> the database's internal caches. One could also imagine a feature like this 
> providing functionality similar to a foreign data wrapper in other databases.
> 
> I don't think the assumption that "virtual tables will always be small and 
> always fit in memory" is a safe one.
> 
> I don't think we should implicitly add "ALLOW FILTERING" to all queries 
> against virtual tables because of this, in addition to concern with departing 
> from standard CQL semantics for a type of tables deemed special.
> 
> – Scott
> 
>> On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:
>> 
>> 
>> Hello Stefan,
>> 
>> Regarding the decision to implicitly enable ALLOW FILTERING for
>> virtual tables, which also makes sense to me, it may be necessary to
>> consider changing the clustering columns in the virtual table metadata
>> to regular columns as well. The reasons are the same as mentioned
>> earlier: the virtual tables hold their data in memory, thus we do not
>> benefit from the advantages of ordered data (e.g. the ClientsTable and
>> its ClusteringColumn(PORT)).
>> 
>> Changing the clustering column to a regular column may simplify the
>> virtual table data model, but I'm afraid it may affect users who rely
>> on the table metadata.
>> 
>> 
>> 
>> On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña  wrote:
>>> 
>>> I think removing the need for ALLOW FILTERING on virtual tables makes sense 
>>> and would be quite useful for operators.
>>> 
>>> That guard exists for performance issues that shouldn't occur on virtual 
>>> tables. We also have a flag in case some future virtual table 
>>> implementation has limitations regarding filtering, although it seems it's 
>>> not the case with any of the existing virtual tables.
>>> 
>>> It is not like we would promote bad habits because virtual tables are meant 
>>> to be queried by operators / administrators only.
>>> 
>>> 
>>> It might even be quite the opposite, since in the current situation users 
>>> might get used to routinely use ALLOW FILTERING for querying their virtual 
>>> tables.
>>> 
>>> It has been mentioned on the #cassandra-dev Slack thread where this started 
>>> (1) that it's kind of an API inconsistency to allow querying by non-primary 
>>> keys on virtual tables without ALLOW FILTERING, whereas it's required for 
>>> regular tables. I think that a simply doc update saying that virtual 
>>> tables, which are not regular tables, support filtering would be enough. 
>>> Virtual tables are well identified by both the keyspace they belong to and 
>>> doc, so users shouldn't have trouble knowing whether a table is virtual. It 
>>> would be similar to the current exception for ALLOW FILTERING, where one 
>>> needs to use it unless the table has an index for the queried column.
>>> 
>>> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329
>>> 
>>> On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan 
>>>  wrote:
 
 Hi list,
 
 the content of virtual tables is held in memory (and / or is fetched every 
 time upon request). While doing queries against such table for a column 
 outside of primary key, normally, users are required to specify ALLOW 
 FILTERING. This makes total sense for "ordinary tables" for applications 
 to have performant and effective queries but it kinds of loses the 
 applicability for virtual tables when it literally holds just handful of 
 entries in memory and it just does not matter, does it?
 
 What do you think about implicitly allowing filtering for virtual tables 
 so we save ourselves from these pesky errors when we want to query 
 arbitrary column and we need to satisfy CQL spec just to do that?
 
 It is not like 

Important news about Cassandra Summit

[Patrick McFadin]

*Hello Cassandra Community,We all see what’s happening in tech right now.
Cuts are being made, and budgets are frozen. For Cassandra Summit, this has
translated to low sponsorship and registrations. The program committee has
been discussing options with the Linux Foundation events team, and the
decision was made to move Cassandra Summit to December 12-13. You’ll see
something official from the Linux Foundation soon. This isn’t what anyone
wanted. It’s a challenging time for our community to gather, and that’s
entirely the point of a Cassandra Summit. Hopefully, this provides enough
space to have the Summit we want and need. Between now and December, the
DataStax community team is ramping up a plan B to keep up the project
momentum during this downturn and facilitate community information sharing.
Cassandra 5.0 is coming, and it’s going to be game-changing. No way we are
waiting until December to talk about it! The plan is to have a virtual
event (online) on March 14 and a series of city-specific Cassandra Days in
the coming months. It’s hard for our community to get out, so we’ll come to
you. More information will follow in the next few days. I want to reassure
you this isn’t specific to our community. I’ve been hearing from many that
you were trying anything to get to San Jose in March, but budgets wouldn’t
allow for any non-essential travel. When I started hearing the same thing
from speakers, then sponsors, I knew this was a large-scale problem. We all
know people impacted by layoffs, and I’m sure many are personally affected.
Let’s come together as a community and help each other. If you have open
positions, call them out in this email thread or #cassandra in the ASF
slack.I want to thank the Linux Foundation Events team personally. They are
exceptional professionals and worked quickly to get us back on track. There
was a rush of events trying to postpone to later in the year, but they were
able to get us a new date. They are as protective of conference uptime like
you are about database uptime. More info to follow. ThanksPatrick*

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Miklosovic, Stefan]

While that might technically work, Benedict, I am afraid that if we enable 
users to have this kind of power, they would start to set ALLOW FILTERING here 
and there in order to not think twice about their data model so they can just 
call it a day.

At the same time, we have a guardrail for allowing filtering. If we set a table 
to be allowed to be filtered on and we would have a guardrail to forbid it, 
which approach would be applied?


From: Benedict 
Sent: Friday, February 3, 2023 22:13
To: dev@cassandra.apache.org
Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables

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.



Why not introduce a general table option that toggles ALLOW FILTERING behaviour 
and just flip it for virtual tables we want this behaviour for? Users can do it 
too, for their own tables for which it’s suitable.

On 3 Feb 2023, at 20:59, Andrés de la Peña  wrote:


For those eventual big virtual tables there is the mentioned flag indicating 
whether the table allows filtering without AF.

I guess the question is how can a user know whether a certain virtual table is 
one of the big ones. That could be specified in the doc for each table, and it 
could also be included in the table properties, so it's displayed by DESCRIBE 
TABLE queries.

On Fri, 3 Feb 2023 at 20:56, Chris Lohfink 
mailto:clohfin...@gmail.com>> wrote:
Just to 2nd what Scott days. While everything is in memory now, it may not be 
in the future, and if we add it implicitly, we are tying ourselves to be in 
memory only. However, I wouldn't -1 the idea.

Another option may be a cqlsh option (ie like expand on/off) to always include 
a flag so it doesnt need to be added or something.

Chris

On Fri, Feb 3, 2023 at 1:24 PM C. Scott Andreas 
mailto:sc...@paradoxica.net>> wrote:
There are some ideas that development community members have kicked around that 
may falsify the assumption that "virtual tables are tiny and will fit in 
memory."

One example is CASSANDRA-14629: Abstract Virtual Table for very large result 
sets
https://issues.apache.org/jira/browse/CASSANDRA-14629

Chris's proposal here is to enable query results from virtual tables to be 
streamed to the client rather than being fully materialized. There are some 
neat possibilities suggested in this ticket, such as debug functionality to 
dump the contents of a raw SSTable via the CQL interface, or the contents of 
the database's internal caches. One could also imagine a feature like this 
providing functionality similar to a foreign data wrapper in other databases.

I don't think the assumption that "virtual tables will always be small and 
always fit in memory" is a safe one.

I don't think we should implicitly add "ALLOW FILTERING" to all queries against 
virtual tables because of this, in addition to concern with departing from 
standard CQL semantics for a type of tables deemed special.

– Scott

On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov 
mailto:mmu...@apache.org>> wrote:


Hello Stefan,

Regarding the decision to implicitly enable ALLOW FILTERING for
virtual tables, which also makes sense to me, it may be necessary to
consider changing the clustering columns in the virtual table metadata
to regular columns as well. The reasons are the same as mentioned
earlier: the virtual tables hold their data in memory, thus we do not
benefit from the advantages of ordered data (e.g. the ClientsTable and
its ClusteringColumn(PORT)).

Changing the clustering column to a regular column may simplify the
virtual table data model, but I'm afraid it may affect users who rely
on the table metadata.



On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña 
mailto:adelap...@apache.org>> wrote:

I think removing the need for ALLOW FILTERING on virtual tables makes sense and 
would be quite useful for operators.

That guard exists for performance issues that shouldn't occur on virtual 
tables. We also have a flag in case some future virtual table implementation 
has limitations regarding filtering, although it seems it's not the case with 
any of the existing virtual tables.

It is not like we would promote bad habits because virtual tables are meant to 
be queried by operators / administrators only.


It might even be quite the opposite, since in the current situation users might 
get used to routinely use ALLOW FILTERING for querying their virtual tables.

It has been mentioned on the #cassandra-dev Slack thread where this started (1) 
that it's kind of an API inconsistency to allow querying by non-primary keys on 
virtual tables without ALLOW FILTERING, whereas it's required for regular 
tables. I think that a simply doc update saying that virtual tables, which are 
not regular tables, support filtering would be enough. Virtual tables are well 
identified by both the keyspace they belong to and doc, so users shouldn't have 

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Benedict]

Why not introduce a general table option that toggles ALLOW FILTERING behaviour and just flip it for virtual tables we want this behaviour for? Users can do it too, for their own tables for which it’s suitable.On 3 Feb 2023, at 20:59, Andrés de la Peña  wrote:For those eventual big virtual tables there is the mentioned flag indicating whether the table allows filtering without AF.I guess the question is how can a user know whether a certain virtual table is one of the big ones. That could be specified in the doc for each table, and it could also be included in the table properties, so it's displayed by DESCRIBE TABLE queries.On Fri, 3 Feb 2023 at 20:56, Chris Lohfink  wrote:Just to 2nd what Scott days. While everything is in memory now, it may not be in the future, and if we add it implicitly, we are tying ourselves to be in memory only. However, I wouldn't -1 the idea. Another option may be a cqlsh option (ie like expand on/off) to always include a flag so it doesnt need to be added or something.ChrisOn Fri, Feb 3, 2023 at 1:24 PM C. Scott Andreas  wrote:There are some ideas that development community members have kicked around that may falsify the assumption that "virtual tables are tiny and will fit in memory."One example is CASSANDRA-14629: Abstract Virtual Table for very large result setshttps://issues.apache.org/jira/browse/CASSANDRA-14629Chris's proposal here is to enable query results from virtual tables to be streamed to the client rather than being fully materialized. There are some neat possibilities suggested in this ticket, such as debug functionality to dump the contents of a raw SSTable via the CQL interface, or the contents of the database's internal caches. One could also imagine a feature like this providing functionality similar to a foreign data wrapper in other databases.I don't think the assumption that "virtual tables will always be small and always fit in memory" is a safe one.I don't think we should implicitly add "ALLOW FILTERING" to all queries against virtual tables because of this, in addition to concern with departing from standard CQL semantics for a type of tables deemed special.– ScottOn Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:Hello Stefan,Regarding the decision to implicitly enable ALLOW FILTERING forvirtual tables, which also makes sense to me, it may be necessary toconsider changing the clustering columns in the virtual table metadatato regular columns as well. The reasons are the same as mentionedearlier: the virtual tables hold their data in memory, thus we do notbenefit from the advantages of ordered data (e.g. the ClientsTable andits ClusteringColumn(PORT)).Changing the clustering column to a regular column may simplify thevirtual table data model, but I'm afraid it may affect users who relyon the table metadata.On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña  wrote:I think removing the need for ALLOW FILTERING on virtual tables makes sense and would be quite useful for operators.That guard exists for performance issues that shouldn't occur on virtual tables. We also have a flag in case some future virtual table implementation has limitations regarding filtering, although it seems it's not the case with any of the existing virtual tables.It is not like we would promote bad habits because virtual tables are meant to be queried by operators / administrators only.It might even be quite the opposite, since in the current situation users might get used to routinely use ALLOW FILTERING for querying their virtual tables.It has been mentioned on the #cassandra-dev Slack thread where this started (1) that it's kind of an API inconsistency to allow querying by non-primary keys on virtual tables without ALLOW FILTERING, whereas it's required for regular tables. I think that a simply doc update saying that virtual tables, which are not regular tables, support filtering would be enough. Virtual tables are well identified by both the keyspace they belong to and doc, so users shouldn't have trouble knowing whether a table is virtual. It would be similar to the current exception for ALLOW FILTERING, where one needs to use it unless the table has an index for the queried column.(1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan  wrote:Hi list,the content of virtual tables is held in memory (and / or is fetched every time upon request). While doing queries against such table for a column outside of primary key, normally, users are required to specify ALLOW FILTERING. This makes total sense for "ordinary tables" for applications to have performant and effective queries but it kinds of loses the applicability for virtual tables when it literally holds just handful of entries in memory and it just does not matter, does it?What do you think about implicitly allowing filtering for virtual tables so we save 

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Chris Lohfink]

Yes, I am not -1. Just that if we do it we should be ok in the future with
some virtual tables that did not have this behavior. Should consider if
this would be confusing. Really should be ok imho since they just would get
the "need allow filtering" error on said future tables.

Chris

On Fri, Feb 3, 2023 at 2:59 PM Andrés de la Peña 
wrote:

> For those eventual big virtual tables there is the mentioned flag
> indicating whether the table allows filtering without AF.
>
> I guess the question is how can a user know whether a certain virtual
> table is one of the big ones. That could be specified in the doc for each
> table, and it could also be included in the table properties, so it's
> displayed by DESCRIBE TABLE queries.
>
> On Fri, 3 Feb 2023 at 20:56, Chris Lohfink  wrote:
>
>> Just to 2nd what Scott days. While everything is in memory now, it may
>> not be in the future, and if we add it implicitly, we are tying ourselves
>> to be in memory only. However, I wouldn't -1 the idea.
>>
>> Another option may be a cqlsh option (ie like expand on/off) to always
>> include a flag so it doesnt need to be added or something.
>>
>> Chris
>>
>> On Fri, Feb 3, 2023 at 1:24 PM C. Scott Andreas 
>> wrote:
>>
>>> There are some ideas that development community members have kicked
>>> around that may falsify the assumption that "virtual tables are tiny and
>>> will fit in memory."
>>>
>>> One example is CASSANDRA-14629: Abstract Virtual Table for very large
>>> result sets
>>> https://issues.apache.org/jira/browse/CASSANDRA-14629
>>>
>>> Chris's proposal here is to enable query results from virtual tables to
>>> be streamed to the client rather than being fully materialized. There are
>>> some neat possibilities suggested in this ticket, such as debug
>>> functionality to dump the contents of a raw SSTable via the CQL interface,
>>> or the contents of the database's internal caches. One could also imagine a
>>> feature like this providing functionality similar to a foreign data wrapper
>>> in other databases.
>>>
>>> I don't think the assumption that "virtual tables will always be small
>>> and always fit in memory" is a safe one.
>>>
>>> I don't think we should implicitly add "ALLOW FILTERING" to all queries
>>> against virtual tables because of this, in addition to concern with
>>> departing from standard CQL semantics for a type of tables deemed special.
>>>
>>> – Scott
>>>
>>> On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:
>>>
>>>
>>> Hello Stefan,
>>>
>>> Regarding the decision to implicitly enable ALLOW FILTERING for
>>> virtual tables, which also makes sense to me, it may be necessary to
>>> consider changing the clustering columns in the virtual table metadata
>>> to regular columns as well. The reasons are the same as mentioned
>>> earlier: the virtual tables hold their data in memory, thus we do not
>>> benefit from the advantages of ordered data (e.g. the ClientsTable and
>>> its ClusteringColumn(PORT)).
>>>
>>> Changing the clustering column to a regular column may simplify the
>>> virtual table data model, but I'm afraid it may affect users who rely
>>> on the table metadata.
>>>
>>>
>>>
>>> On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña 
>>> wrote:
>>>
>>>
>>> I think removing the need for ALLOW FILTERING on virtual tables makes
>>> sense and would be quite useful for operators.
>>>
>>> That guard exists for performance issues that shouldn't occur on virtual
>>> tables. We also have a flag in case some future virtual table
>>> implementation has limitations regarding filtering, although it seems it's
>>> not the case with any of the existing virtual tables.
>>>
>>> It is not like we would promote bad habits because virtual tables are
>>> meant to be queried by operators / administrators only.
>>>
>>>
>>> It might even be quite the opposite, since in the current situation
>>> users might get used to routinely use ALLOW FILTERING for querying their
>>> virtual tables.
>>>
>>> It has been mentioned on the #cassandra-dev Slack thread where this
>>> started (1) that it's kind of an API inconsistency to allow querying by
>>> non-primary keys on virtual tables without ALLOW FILTERING, whereas it's
>>> required for regular tables. I think that a simply doc update saying that
>>> virtual tables, which are not regular tables, support filtering would be
>>> enough. Virtual tables are well identified by both the keyspace they belong
>>> to and doc, so users shouldn't have trouble knowing whether a table is
>>> virtual. It would be similar to the current exception for ALLOW FILTERING,
>>> where one needs to use it unless the table has an index for the queried
>>> column.
>>>
>>> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329
>>>
>>> On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan <
>>> stefan.mikloso...@netapp.com> wrote:
>>>
>>>
>>> Hi list,
>>>
>>> the content of virtual tables is held in memory (and / or is fetched
>>> every time upon request). While doing queries against such table for 

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Andrés de la Peña]

For those eventual big virtual tables there is the mentioned flag
indicating whether the table allows filtering without AF.

I guess the question is how can a user know whether a certain virtual table
is one of the big ones. That could be specified in the doc for each table,
and it could also be included in the table properties, so it's displayed by
DESCRIBE TABLE queries.

On Fri, 3 Feb 2023 at 20:56, Chris Lohfink  wrote:

> Just to 2nd what Scott days. While everything is in memory now, it may not
> be in the future, and if we add it implicitly, we are tying ourselves to be
> in memory only. However, I wouldn't -1 the idea.
>
> Another option may be a cqlsh option (ie like expand on/off) to always
> include a flag so it doesnt need to be added or something.
>
> Chris
>
> On Fri, Feb 3, 2023 at 1:24 PM C. Scott Andreas 
> wrote:
>
>> There are some ideas that development community members have kicked
>> around that may falsify the assumption that "virtual tables are tiny and
>> will fit in memory."
>>
>> One example is CASSANDRA-14629: Abstract Virtual Table for very large
>> result sets
>> https://issues.apache.org/jira/browse/CASSANDRA-14629
>>
>> Chris's proposal here is to enable query results from virtual tables to
>> be streamed to the client rather than being fully materialized. There are
>> some neat possibilities suggested in this ticket, such as debug
>> functionality to dump the contents of a raw SSTable via the CQL interface,
>> or the contents of the database's internal caches. One could also imagine a
>> feature like this providing functionality similar to a foreign data wrapper
>> in other databases.
>>
>> I don't think the assumption that "virtual tables will always be small
>> and always fit in memory" is a safe one.
>>
>> I don't think we should implicitly add "ALLOW FILTERING" to all queries
>> against virtual tables because of this, in addition to concern with
>> departing from standard CQL semantics for a type of tables deemed special.
>>
>> – Scott
>>
>> On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:
>>
>>
>> Hello Stefan,
>>
>> Regarding the decision to implicitly enable ALLOW FILTERING for
>> virtual tables, which also makes sense to me, it may be necessary to
>> consider changing the clustering columns in the virtual table metadata
>> to regular columns as well. The reasons are the same as mentioned
>> earlier: the virtual tables hold their data in memory, thus we do not
>> benefit from the advantages of ordered data (e.g. the ClientsTable and
>> its ClusteringColumn(PORT)).
>>
>> Changing the clustering column to a regular column may simplify the
>> virtual table data model, but I'm afraid it may affect users who rely
>> on the table metadata.
>>
>>
>>
>> On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña 
>> wrote:
>>
>>
>> I think removing the need for ALLOW FILTERING on virtual tables makes
>> sense and would be quite useful for operators.
>>
>> That guard exists for performance issues that shouldn't occur on virtual
>> tables. We also have a flag in case some future virtual table
>> implementation has limitations regarding filtering, although it seems it's
>> not the case with any of the existing virtual tables.
>>
>> It is not like we would promote bad habits because virtual tables are
>> meant to be queried by operators / administrators only.
>>
>>
>> It might even be quite the opposite, since in the current situation users
>> might get used to routinely use ALLOW FILTERING for querying their virtual
>> tables.
>>
>> It has been mentioned on the #cassandra-dev Slack thread where this
>> started (1) that it's kind of an API inconsistency to allow querying by
>> non-primary keys on virtual tables without ALLOW FILTERING, whereas it's
>> required for regular tables. I think that a simply doc update saying that
>> virtual tables, which are not regular tables, support filtering would be
>> enough. Virtual tables are well identified by both the keyspace they belong
>> to and doc, so users shouldn't have trouble knowing whether a table is
>> virtual. It would be similar to the current exception for ALLOW FILTERING,
>> where one needs to use it unless the table has an index for the queried
>> column.
>>
>> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329
>>
>> On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> wrote:
>>
>>
>> Hi list,
>>
>> the content of virtual tables is held in memory (and / or is fetched
>> every time upon request). While doing queries against such table for a
>> column outside of primary key, normally, users are required to specify
>> ALLOW FILTERING. This makes total sense for "ordinary tables" for
>> applications to have performant and effective queries but it kinds of loses
>> the applicability for virtual tables when it literally holds just handful
>> of entries in memory and it just does not matter, does it?
>>
>> What do you think about implicitly allowing filtering for virtual tables
>> so we save 

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Chris Lohfink]

Just to 2nd what Scott days. While everything is in memory now, it may not
be in the future, and if we add it implicitly, we are tying ourselves to be
in memory only. However, I wouldn't -1 the idea.

Another option may be a cqlsh option (ie like expand on/off) to always
include a flag so it doesnt need to be added or something.

Chris

On Fri, Feb 3, 2023 at 1:24 PM C. Scott Andreas 
wrote:

> There are some ideas that development community members have kicked around
> that may falsify the assumption that "virtual tables are tiny and will fit
> in memory."
>
> One example is CASSANDRA-14629: Abstract Virtual Table for very large
> result sets
> https://issues.apache.org/jira/browse/CASSANDRA-14629
>
> Chris's proposal here is to enable query results from virtual tables to be
> streamed to the client rather than being fully materialized. There are some
> neat possibilities suggested in this ticket, such as debug functionality to
> dump the contents of a raw SSTable via the CQL interface, or the contents
> of the database's internal caches. One could also imagine a feature like
> this providing functionality similar to a foreign data wrapper in other
> databases.
>
> I don't think the assumption that "virtual tables will always be small and
> always fit in memory" is a safe one.
>
> I don't think we should implicitly add "ALLOW FILTERING" to all queries
> against virtual tables because of this, in addition to concern with
> departing from standard CQL semantics for a type of tables deemed special.
>
> – Scott
>
> On Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  wrote:
>
>
> Hello Stefan,
>
> Regarding the decision to implicitly enable ALLOW FILTERING for
> virtual tables, which also makes sense to me, it may be necessary to
> consider changing the clustering columns in the virtual table metadata
> to regular columns as well. The reasons are the same as mentioned
> earlier: the virtual tables hold their data in memory, thus we do not
> benefit from the advantages of ordered data (e.g. the ClientsTable and
> its ClusteringColumn(PORT)).
>
> Changing the clustering column to a regular column may simplify the
> virtual table data model, but I'm afraid it may affect users who rely
> on the table metadata.
>
>
>
> On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña 
> wrote:
>
>
> I think removing the need for ALLOW FILTERING on virtual tables makes
> sense and would be quite useful for operators.
>
> That guard exists for performance issues that shouldn't occur on virtual
> tables. We also have a flag in case some future virtual table
> implementation has limitations regarding filtering, although it seems it's
> not the case with any of the existing virtual tables.
>
> It is not like we would promote bad habits because virtual tables are
> meant to be queried by operators / administrators only.
>
>
> It might even be quite the opposite, since in the current situation users
> might get used to routinely use ALLOW FILTERING for querying their virtual
> tables.
>
> It has been mentioned on the #cassandra-dev Slack thread where this
> started (1) that it's kind of an API inconsistency to allow querying by
> non-primary keys on virtual tables without ALLOW FILTERING, whereas it's
> required for regular tables. I think that a simply doc update saying that
> virtual tables, which are not regular tables, support filtering would be
> enough. Virtual tables are well identified by both the keyspace they belong
> to and doc, so users shouldn't have trouble knowing whether a table is
> virtual. It would be similar to the current exception for ALLOW FILTERING,
> where one needs to use it unless the table has an index for the queried
> column.
>
> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329
>
> On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>
> Hi list,
>
> the content of virtual tables is held in memory (and / or is fetched every
> time upon request). While doing queries against such table for a column
> outside of primary key, normally, users are required to specify ALLOW
> FILTERING. This makes total sense for "ordinary tables" for applications to
> have performant and effective queries but it kinds of loses the
> applicability for virtual tables when it literally holds just handful of
> entries in memory and it just does not matter, does it?
>
> What do you think about implicitly allowing filtering for virtual tables
> so we save ourselves from these pesky errors when we want to query
> arbitrary column and we need to satisfy CQL spec just to do that?
>
> It is not like we would promote bad habits because virtual tables are
> meant to be queried by operators / administrators only.
>
> We can also explicitly document this behavior.
>
> Among other options, we may try to implement secondary indices on virtual
> tables but I am not completely sure this is what we want because its
> complexity etc. Is it even necessary to put such complex logic in place
> just to be 

Re: Welcome Patrick McFadin as Cassandra Committer

[C. Scott Andreas]

Congratulations, Patrick!On Feb 2, 2023, at 9:46 PM, Berenguer Blasi 
 wrote:Welcome!On 3/2/23 4:09, Vinay Chella 
wrote:Well deserved one, Congratulations, Patrick. On Fri, Feb 3, 2023 at 4:01
   AM Josh McKenzie 
   wrote:Congrats Patrick! Well deserved.On Thu, Feb 2, 2023, at 5:25 
PM, Molly Monroy wrote:Congrats, Patrick... much deserved!On Thu, Feb 2, 2023 
at 1:59 PM Derek
   Chen-Becker 
   wrote:Congrats!On Thu, Feb 2, 2023 at 10:58 AM
   Benjamin Lerer 
   wrote:The PMC members are pleased to announce
   that Patrick McFadin has acceptedthe invitation to 
become committer today.Thanks a lot, Patrick, for everything
   you have done for this project and its
   community through the years.Congratulations and 
welcome!The Apache Cassandra PMC 
members--+---+|
   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  
|+---+-- 
Thanks,Vinay Chella

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[C. Scott Andreas]

There are some ideas that development community members have kicked around that may falsify the assumption that "virtual tables are 
tiny and will fit in memory."One example is CASSANDRA-14629: Abstract Virtual Table for very large result 
setshttps://issues.apache.org/jira/browse/CASSANDRA-14629Chris's proposal here is to enable query results from virtual tables to be 
streamed to the client rather than being fully materialized. There are some neat possibilities suggested in this ticket, such as debug 
functionality to dump the contents of a raw SSTable via the CQL interface, or the contents of the database's internal caches. One could 
also imagine a feature like this providing functionality similar to a foreign data wrapper in other databases.I don't think the 
assumption that "virtual tables will always be small and always fit in memory" is a safe one.I don't think we should implicitly 
add "ALLOW FILTERING" to all queries against virtual tables because of this, in addition to concern with departing from 
standard CQL semantics for a type of tables deemed special.– ScottOn Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  
wrote:Hello Stefan,Regarding the decision to implicitly enable ALLOW FILTERING forvirtual tables, which also makes sense to me, it may be 
necessary toconsider changing the clustering columns in the virtual table metadatato regular columns as well. The reasons are the same as 
mentionedearlier: the virtual tables hold their data in memory, thus we do notbenefit from the advantages of ordered data (e.g. the 
ClientsTable andits ClusteringColumn(PORT)).Changing the clustering column to a regular column may simplify thevirtual table data model, 
but I'm afraid it may affect users who relyon the table metadata.On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña 
 wrote:I think removing the need for ALLOW FILTERING on virtual tables makes sense and would be quite useful 
for operators.That guard exists for performance issues that shouldn't occur on virtual tables. We also have a flag in case some future 
virtual table implementation has limitations regarding filtering, although it seems it's not the case with any of the existing virtual 
tables.It is not like we would promote bad habits because virtual tables are meant to be queried by operators / administrators only.It 
might even be quite the opposite, since in the current situation users might get used to routinely use ALLOW FILTERING for querying their 
virtual tables.It has been mentioned on the #cassandra-dev Slack thread where this started (1) that it's kind of an API inconsistency to 
allow querying by non-primary keys on virtual tables without ALLOW FILTERING, whereas it's required for regular tables. I think that a 
simply doc update saying that virtual tables, which are not regular tables, support filtering would be enough. Virtual tables are well 
identified by both the keyspace they belong to and doc, so users shouldn't have trouble knowing whether a table is virtual. It would be 
similar to the current exception for ALLOW FILTERING, where one needs to use it unless the table has an index for the queried column.(1) 
https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan 
 wrote:Hi list,the content of virtual tables is held in memory (and / or is fetched every time upon 
request). While doing queries against such table for a column outside of primary key, normally, users are required to specify ALLOW 
FILTERING. This makes total sense for "ordinary tables" for applications to have performant and effective queries but it kinds 
of loses the applicability for virtual tables when it literally holds just handful of entries in memory and it just does not matter, does 
it?What do you think about implicitly allowing filtering for virtual tables so we save ourselves from these pesky errors when we want to 
query arbitrary column and we need to satisfy CQL spec just to do that?It is not like we would promote bad habits because virtual tables 
are meant to be queried by operators / administrators only.We can also explicitly document this behavior.Among other options, we may try 
to implement secondary indices on virtual tables but I am not completely sure this is what we want because its complexity etc. Is it even 
necessary to put such complex logic in place just to be able to select any column on few entries in memory?I put together a draft here 
(1). It would be ever possible to implicitly allow filtering on virtual tables only and it would be implementator's responsibility to 
decide that, per table.For all virtual tables we currently have, I would enable this everywhere. I do not think there is any virtual 
table where we would not want to enable it or where people HAVE TO specify that.(1) https://github.com/apache/cassandra/pull/2131

Re: [DISCUSS] Merging incremental feature work

[Derek Chen-Becker]

I think Henrik has a lot of good points. However, I want to point out that
JDK upgrades are non-optional over the fullness of time, so it might be
worth carving out a specific process for that work. In a similar vein,
security patches also Just Need to Merge™, so I'm a little hesitant when I
see that discussed alongside CEPs. Perhaps the work is done on a feature
branch to *defer* impact to trunk, but at some point we have to pay the
piper and deal with whatever the merge fallout is, whether that's
complexity or performance that needs to be addressed.

Cheers,

Derek

On Fri, Feb 3, 2023 at 9:24 AM Ekaterina Dimitrova 
wrote:

> I am all in for incremental changes which are fine to get into release.
> In the case of JDK 17 I know dependencies which need to be updated for
> Java 17 but they still work with Java8 and 11 so it is fine to update them
> before the switch.
> So while some blockers are removed, I do the updates in parallel to trunk.
>
> I also like the points made around volunteers who got pulled and not
> blocking ourselves on not finished features which are partially committed.
>
> Best regards,
> Ekaterina
>
>
> On Fri, 3 Feb 2023 at 9:37, Josh McKenzie  wrote:
>
>> *Suddenly, you get to be doubly managerial for making _two_
>> inconsequential decisions - the wrong one _and_ the right one.*
>>
>> Something to aspire to. :)
>>
>> On Fri, Feb 3, 2023, at 9:20 AM, Henrik Ingo wrote:
>>
>> I've been an unusually active debater recently, so it might be
>> appropriate to start with a reminder/disclaimer that I'm not actually a
>> Cassandra contributor in any way(*), but I choose to share some thoughts
>> where I feel that sharing experiences from other open source database
>> projects can be of use to the discussion,
>>
>> *) No. Even if I agree with the idea that there are many types of
>> contributions other than code, the only thing I have contributed is
>> opinions :-D
>>
>>
>> As I think I mentioned in an Accord related thread, there are two
>> desirable goals at odds here:
>> 1. It is indeed better to merge smaller increments of work into trunk.
>> And to do this more frequently.
>> 2. On the other hand if we want to have an always shippable trunk with a
>> fixed date for feature freeze, it implies that only complete, or at least
>> harmless/inactive units of work can be merged to trunk.
>>
>> To give a specific example, I'll tell the story of the MySQL
>> transactional storage engine called Falcon... (Cue Disney soundtrack
>> featuring a harp, and blurring image...)
>>
>> As Oracle acquired the only transactional storage engine for MySQL,
>> InnoDB, it became a strategic priority to develop a new, in house engine
>> that could replace InnoDB in functionality. This project was codenamed
>> Falcon. Since it was the top priority for MySQL 6.0, it was developed in
>> the "main" v6.0 branch, because it was the definition of MySQL 6. The
>> release date would be whenever Falcon v1 is ready. Over time other
>> features, such as partitioning, transactional backups... were also built
>> into the main feature branch, and they depended on Falcon or were
>> Falcon-only.
>>
>> There was only one problem: Falcon never worked. In the end the v6.0
>> development branch just had to be abandoned and to this date MySQL has
>> never released a version 6. They had to skip a major version number because
>> of this.
>>
>> (As an epilogue that at least I personally was very amused with: When
>> Oracle had to argue their case with the EU Commission that they would be
>> allowed to acquire MySQL, one of the commitments Oracle lawyer made was to
>> continue to develop *and release* MySQL version 6.0. I read the
>> almost-legally-binding statement, and thought yeah good luck with that!)
>>
>>
>> I wasn't involved in the active development, but possibly a similar
>> example could be the TPC architecture introduced in DSE 6.0. (A Cassandra
>> derived proprietary product that I worked on some time ago.) At least by
>> the time I was involved, I can't say that the performance resulting from
>> that work would have been a net positive to the full population of
>> workloads. But because it had been developed directly in the main 6.0
>> branch, and because it is so invasive and core to everything else, it also
>> wasn't possible to roll back its introduction.
>>
>> Finally, in an open source project, it's good to remember that we are all
>> volunteers here, in some sense, and sometimes it could happen that
>> development of a feature stops half way because its developer disappears
>> and nobody else picks it up.
>>
>>
>>
>> So, returning back to this day and this database... Basically what you
>> want to avoid is to paint yourself into a corner, and particularly the
>> wrong corner. So the way I would answer this question is that large bodies
>> of work should:
>>  - Refactoring that is a) harmless, and/or b) improves the codebase
>> anyway, should be merged early into trunk.
>>  - The main body of the new functionality 

Re: [DISCUSS] Merging incremental feature work

[Ekaterina Dimitrova]

I am all in for incremental changes which are fine to get into release.
In the case of JDK 17 I know dependencies which need to be updated for Java
17 but they still work with Java8 and 11 so it is fine to update them
before the switch.
So while some blockers are removed, I do the updates in parallel to trunk.

I also like the points made around volunteers who got pulled and not
blocking ourselves on not finished features which are partially committed.

Best regards,
Ekaterina


On Fri, 3 Feb 2023 at 9:37, Josh McKenzie  wrote:

> *Suddenly, you get to be doubly managerial for making _two_
> inconsequential decisions - the wrong one _and_ the right one.*
>
> Something to aspire to. :)
>
> On Fri, Feb 3, 2023, at 9:20 AM, Henrik Ingo wrote:
>
> I've been an unusually active debater recently, so it might be appropriate
> to start with a reminder/disclaimer that I'm not actually a Cassandra
> contributor in any way(*), but I choose to share some thoughts where I feel
> that sharing experiences from other open source database projects can be of
> use to the discussion,
>
> *) No. Even if I agree with the idea that there are many types of
> contributions other than code, the only thing I have contributed is
> opinions :-D
>
>
> As I think I mentioned in an Accord related thread, there are two
> desirable goals at odds here:
> 1. It is indeed better to merge smaller increments of work into trunk. And
> to do this more frequently.
> 2. On the other hand if we want to have an always shippable trunk with a
> fixed date for feature freeze, it implies that only complete, or at least
> harmless/inactive units of work can be merged to trunk.
>
> To give a specific example, I'll tell the story of the MySQL transactional
> storage engine called Falcon... (Cue Disney soundtrack featuring a harp,
> and blurring image...)
>
> As Oracle acquired the only transactional storage engine for MySQL,
> InnoDB, it became a strategic priority to develop a new, in house engine
> that could replace InnoDB in functionality. This project was codenamed
> Falcon. Since it was the top priority for MySQL 6.0, it was developed in
> the "main" v6.0 branch, because it was the definition of MySQL 6. The
> release date would be whenever Falcon v1 is ready. Over time other
> features, such as partitioning, transactional backups... were also built
> into the main feature branch, and they depended on Falcon or were
> Falcon-only.
>
> There was only one problem: Falcon never worked. In the end the v6.0
> development branch just had to be abandoned and to this date MySQL has
> never released a version 6. They had to skip a major version number because
> of this.
>
> (As an epilogue that at least I personally was very amused with: When
> Oracle had to argue their case with the EU Commission that they would be
> allowed to acquire MySQL, one of the commitments Oracle lawyer made was to
> continue to develop *and release* MySQL version 6.0. I read the
> almost-legally-binding statement, and thought yeah good luck with that!)
>
>
> I wasn't involved in the active development, but possibly a similar
> example could be the TPC architecture introduced in DSE 6.0. (A Cassandra
> derived proprietary product that I worked on some time ago.) At least by
> the time I was involved, I can't say that the performance resulting from
> that work would have been a net positive to the full population of
> workloads. But because it had been developed directly in the main 6.0
> branch, and because it is so invasive and core to everything else, it also
> wasn't possible to roll back its introduction.
>
> Finally, in an open source project, it's good to remember that we are all
> volunteers here, in some sense, and sometimes it could happen that
> development of a feature stops half way because its developer disappears
> and nobody else picks it up.
>
>
>
> So, returning back to this day and this database... Basically what you
> want to avoid is to paint yourself into a corner, and particularly the
> wrong corner. So the way I would answer this question is that large bodies
> of work should:
>  - Refactoring that is a) harmless, and/or b) improves the codebase
> anyway, should be merged early into trunk.
>  - The main body of the new functionality should be developed in a feature
> branch up until some kind of MVP stage. This means that by the time it is
> proposed for merge, a) it has been tested to both be of good quality and
> that it actually provides the benefit it set out to implement. This means
> that merging it to trunk will be a net improvement, always.
>  - After that first big MVP merge, additional functionality of course
> could be developed directly against trunk.
>  - For patches that are very clean and self contained, for example in
> their own Java package, it doesn't really matter, because they are easy to
> roll back if needed. They can be developed against trunk.
>
> So applying this to Josh's examples:
>
> 1) I assume JDK17 support is invasive, so that 

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Maxim Muzafarov]

Hello Stefan,

Regarding the decision to implicitly enable ALLOW FILTERING for
virtual tables, which also makes sense to me, it may be necessary to
consider changing the clustering columns in the virtual table metadata
to regular columns as well. The reasons are the same as mentioned
earlier: the virtual tables hold their data in memory, thus we do not
benefit from the advantages of ordered data (e.g. the ClientsTable and
its ClusteringColumn(PORT)).

Changing the clustering column to a regular column may simplify the
virtual table data model, but I'm afraid it may affect users who rely
on the table metadata.



On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña  wrote:
>
> I think removing the need for ALLOW FILTERING on virtual tables makes sense 
> and would be quite useful for operators.
>
> That guard exists for performance issues that shouldn't occur on virtual 
> tables. We also have a flag in case some future virtual table implementation 
> has limitations regarding filtering, although it seems it's not the case with 
> any of the existing virtual tables.
>
> It is not like we would promote bad habits because virtual tables are meant 
> to be queried by operators / administrators only.
>
>
> It might even be quite the opposite, since in the current situation users 
> might get used to routinely use ALLOW FILTERING for querying their virtual 
> tables.
>
> It has been mentioned on the #cassandra-dev Slack thread where this started 
> (1) that it's kind of an API inconsistency to allow querying by non-primary 
> keys on virtual tables without ALLOW FILTERING, whereas it's required for 
> regular tables. I think that a simply doc update saying that virtual tables, 
> which are not regular tables, support filtering would be enough. Virtual 
> tables are well identified by both the keyspace they belong to and doc, so 
> users shouldn't have trouble knowing whether a table is virtual. It would be 
> similar to the current exception for ALLOW FILTERING, where one needs to use 
> it unless the table has an index for the queried column.
>
> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329
>
> On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan 
>  wrote:
>>
>> Hi list,
>>
>> the content of virtual tables is held in memory (and / or is fetched every 
>> time upon request). While doing queries against such table for a column 
>> outside of primary key, normally, users are required to specify ALLOW 
>> FILTERING. This makes total sense for "ordinary tables" for applications to 
>> have performant and effective queries but it kinds of loses the 
>> applicability for virtual tables when it literally holds just handful of 
>> entries in memory and it just does not matter, does it?
>>
>> What do you think about implicitly allowing filtering for virtual tables so 
>> we save ourselves from these pesky errors when we want to query arbitrary 
>> column and we need to satisfy CQL spec just to do that?
>>
>> It is not like we would promote bad habits because virtual tables are meant 
>> to be queried by operators / administrators only.
>>
>> We can also explicitly document this behavior.
>>
>> Among other options, we may try to implement secondary indices on virtual 
>> tables but I am not completely sure this is what we want because its 
>> complexity etc. Is it even necessary to put such complex logic in place just 
>> to be able to select any column on few entries in memory?
>>
>> I put together a draft here (1). It would be ever possible to implicitly 
>> allow filtering on virtual tables only and it would be implementator's 
>> responsibility to decide that, per table.
>>
>> For all virtual tables we currently have, I would enable this everywhere. I 
>> do not think there is any virtual table where we would not want to enable it 
>> or where people HAVE TO specify that.
>>
>> (1) https://github.com/apache/cassandra/pull/2131

Re: [DISCUSS] Merging incremental feature work

[Josh McKenzie]

> *Suddenly, you get to be doubly managerial for making _two_ inconsequential 
> decisions - the wrong one _and_ the right one.* 
Something to aspire to. :)

On Fri, Feb 3, 2023, at 9:20 AM, Henrik Ingo wrote:
> I've been an unusually active debater recently, so it might be appropriate to 
> start with a reminder/disclaimer that I'm not actually a Cassandra 
> contributor in any way(*), but I choose to share some thoughts where I feel 
> that sharing experiences from other open source database projects can be of 
> use to the discussion,
> 
> *) No. Even if I agree with the idea that there are many types of 
> contributions other than code, the only thing I have contributed is opinions 
> :-D
> 
> 
> As I think I mentioned in an Accord related thread, there are two desirable 
> goals at odds here:
> 1. It is indeed better to merge smaller increments of work into trunk. And to 
> do this more frequently.
> 2. On the other hand if we want to have an always shippable trunk with a 
> fixed date for feature freeze, it implies that only complete, or at least 
> harmless/inactive units of work can be merged to trunk.
> 
> To give a specific example, I'll tell the story of the MySQL transactional 
> storage engine called Falcon... (Cue Disney soundtrack featuring a harp, and 
> blurring image...)
> 
> As Oracle acquired the only transactional storage engine for MySQL, InnoDB, 
> it became a strategic priority to develop a new, in house engine that could 
> replace InnoDB in functionality. This project was codenamed Falcon. Since it 
> was the top priority for MySQL 6.0, it was developed in the "main" v6.0 
> branch, because it was the definition of MySQL 6. The release date would be 
> whenever Falcon v1 is ready. Over time other features, such as partitioning, 
> transactional backups... were also built into the main feature branch, and 
> they depended on Falcon or were Falcon-only.
> 
> There was only one problem: Falcon never worked. In the end the v6.0 
> development branch just had to be abandoned and to this date MySQL has never 
> released a version 6. They had to skip a major version number because of this.
> 
> (As an epilogue that at least I personally was very amused with: When Oracle 
> had to argue their case with the EU Commission that they would be allowed to 
> acquire MySQL, one of the commitments Oracle lawyer made was to continue to 
> develop *and release* MySQL version 6.0. I read the almost-legally-binding 
> statement, and thought yeah good luck with that!)
> 
> 
> I wasn't involved in the active development, but possibly a similar example 
> could be the TPC architecture introduced in DSE 6.0. (A Cassandra derived 
> proprietary product that I worked on some time ago.) At least by the time I 
> was involved, I can't say that the performance resulting from that work would 
> have been a net positive to the full population of workloads. But because it 
> had been developed directly in the main 6.0 branch, and because it is so 
> invasive and core to everything else, it also wasn't possible to roll back 
> its introduction.
> 
> Finally, in an open source project, it's good to remember that we are all 
> volunteers here, in some sense, and sometimes it could happen that 
> development of a feature stops half way because its developer disappears and 
> nobody else picks it up.
> 
> 
> 
> So, returning back to this day and this database... Basically what you want 
> to avoid is to paint yourself into a corner, and particularly the wrong 
> corner. So the way I would answer this question is that large bodies of work 
> should:
>  - Refactoring that is a) harmless, and/or b) improves the codebase anyway, 
> should be merged early into trunk.
>  - The main body of the new functionality should be developed in a feature 
> branch up until some kind of MVP stage. This means that by the time it is 
> proposed for merge, a) it has been tested to both be of good quality and that 
> it actually provides the benefit it set out to implement. This means that 
> merging it to trunk will be a net improvement, always.
>  - After that first big MVP merge, additional functionality of course could 
> be developed directly against trunk.
>  - For patches that are very clean and self contained, for example in their 
> own Java package, it doesn't really matter, because they are easy to roll 
> back if needed. They can be developed against trunk.
> 
> So applying this to Josh's examples:
> 
> 1) I assume JDK17 support is invasive, so that would suggest a feature 
> branch. However, the next question is, is there any risk involved in this 
> work (like Falcon for MySQL). Hypothetically it could be that Java 17 has 
> worse performance than Java 11, or some other blocking problem is 
> encountered. But in practice we probably estimate that this risk is small. In 
> such a case JDK17 support could indeed be developed with small patches 
> directly against trunk, but this would be an exception to the rule!
> 
> 2) To 

Re: CASSANDRA-14227 removing the 2038 limit

[Henrik Ingo]

In that case I agree that increasing from 20 years is an interesting
opportunity but clearly out of scope for your current ticket.

On Fri, Feb 3, 2023 at 3:48 PM Berenguer Blasi 
wrote:

> Hi,
>
> 20y is the current and historic value. 68y is what an integer can
> accommodate hence the current 2038 limit since the 1970 Unix epoch. I
> wouldn't make it a configurable value, off the top of my head it would make
> for some interesting bugs and debugging sessions when nodes had different
> values. Food for another ticket in any case imo.
>
> Regards
> On 3/2/23 14:18, Henrik Ingo wrote:
>
> Naive PHB questions to follow...
>
> Why are 68y and 20y special? Could you pick any value? Could we allow it
> to be configurable? (Last one probably overkill, just asking to
> understand...)
>
> If we can pick any values we want, instinctively I would personally
> suggest to have TTL higher than 20 years, but also kicking the can further
> than 2035, which is only 13 years from now. Just to suggest a specific
> number, why not 35y and 2071?
>
> henrik
>
> On Fri, Feb 3, 2023 at 12:32 PM Berenguer Blasi 
> wrote:
>
>> Hi All,
>>
>> a version using Uints, 20y max TTL and kicking the can down the road
>> until 2086 has been put up for review #justfyi
>>
>> Regards
>> On 15/11/22 7:06, Berenguer Blasi wrote:
>>
>> Hi all,
>>
>> thanks for your answers!.
>>
>> To Benedict's point: In terms of the uvint enconding of deletionTime i.e.
>> it is true it happens here
>> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SerializationHeader.java#L170.
>> But we also have a DeletionTime serializer here
>> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/DeletionTime.java#L166
>> that is writing an int and a long that would now write 2 longs.
>>
>> TTL itself (the delta) remains an int in the new PR so it should have no
>> effect in size.
>>
>> Did I reference the correct parts of the codebase? No sstable expert here.
>> On 14/11/22 19:28, Josh McKenzie wrote:
>>
>> in 2035 we'd hit the same problem again.
>>
>> In terms of "kicking a can down the road", this would be a pretty
>> vigorous kick. I wouldn't push back against this deferral. :)
>>
>> On Mon, Nov 14, 2022, at 9:28 AM, Benedict wrote:
>>
>>
>> I’m confused why we see *any* increase in sstable size - TTLs and
>> deletion times are already written as unsigned vints as offsets from an
>> sstable epoch for each value.
>>
>> I would dig in more carefully to explore why you’re seeing this increase?
>> For the same data there should be no change to size on disk.
>>
>>
>> On 14 Nov 2022, at 06:36, C. Scott Andreas 
>>  wrote:
>>
>> A 2-3% increase in storage volume is roughly equivalent to giving up the
>> gain from LZ4 -> LZ4HC, or a one to two-level bump in Zstandard compression
>> levels. This regression could be very expensive for storage-bound use cases.
>>
>> From the perspective of storage overhead, the unsigned int approach
>> sounds preferable.
>>
>> On Nov 13, 2022, at 10:13 PM, Berenguer Blasi 
>>  wrote:
>>
>> 
>>
>> Hi all,
>>
>> We have done some more research on c14227. The current patch for
>> CASSANDRA-14227 solves the TTL limit issue by switching TTL to long instead
>> of int. This approach does not have a negative impact on memtable memory
>> usage, as C* controles the memory used by the Memtable, but based on our
>> testing it increases the bytes flushed by 4 to 7% and the byte on disk by 2
>> to 3%.
>>
>> As a mitigation to this problem it is possible to encode
>> *localDeletionTime* as a vint. It results in a 1% improvement but might
>> cause additional computations during compaction or some other operations.
>>
>> Benedict's proposal to keep on using ints for TTL but as a delta to
>> nowInSecond would work for memtables but not for work in the SSTable where
>> nowInSecond does not exist. By consequence we would still suffer from the
>> impact on byte flushed and bytes on disk.
>>
>> Another approach that was suggested is the use of unsigned integer. Java
>> 8 has an unsigned integer API that would allow us to use unsigned int for
>> TTLs. Based on computation unsigned ints would give us a maximum time of
>> 136 years since the Unix Epoch and therefore a maximum expiration timestamp
>> in 2106. We would have to keep TTL at 20y instead of 68y to give us enough
>> breathing room though, otherwise in 2035 we'd hit the same problem again.
>>
>> Happy to hear opinions.
>> On 18/10/22 10:56, Berenguer Blasi wrote:
>>
>> Hi,
>>
>> apologies for the late reply as I have been OOO. I have done some
>> profiling and results look virtually identical on trunk and 14227. I have
>> attached some screenshots to the ticket
>> https://issues.apache.org/jira/browse/CASSANDRA-14227. Unless my eyes
>> are fooling me everything in the jfrs look the same.
>>
>> Regards
>> On 30/9/22 9:44, Berenguer Blasi wrote:
>>
>> Hi Benedict,
>>
>> thanks for the reply! Yes some profiling is probably needed, then we can
>> see if 

Re: [DISCUSS] Merging incremental feature work

[Henrik Ingo]

I've been an unusually active debater recently, so it might be appropriate
to start with a reminder/disclaimer that I'm not actually a Cassandra
contributor in any way(*), but I choose to share some thoughts where I feel
that sharing experiences from other open source database projects can be of
use to the discussion,

*) No. Even if I agree with the idea that there are many types of
contributions other than code, the only thing I have contributed is
opinions :-D


As I think I mentioned in an Accord related thread, there are two desirable
goals at odds here:
1. It is indeed better to merge smaller increments of work into trunk. And
to do this more frequently.
2. On the other hand if we want to have an always shippable trunk with a
fixed date for feature freeze, it implies that only complete, or at least
harmless/inactive units of work can be merged to trunk.

To give a specific example, I'll tell the story of the MySQL transactional
storage engine called Falcon... (Cue Disney soundtrack featuring a harp,
and blurring image...)

As Oracle acquired the only transactional storage engine for MySQL, InnoDB,
it became a strategic priority to develop a new, in house engine that could
replace InnoDB in functionality. This project was codenamed Falcon. Since
it was the top priority for MySQL 6.0, it was developed in the "main" v6.0
branch, because it was the definition of MySQL 6. The release date would be
whenever Falcon v1 is ready. Over time other features, such as
partitioning, transactional backups... were also built into the main
feature branch, and they depended on Falcon or were Falcon-only.

There was only one problem: Falcon never worked. In the end the v6.0
development branch just had to be abandoned and to this date MySQL has
never released a version 6. They had to skip a major version number because
of this.

(As an epilogue that at least I personally was very amused with: When
Oracle had to argue their case with the EU Commission that they would be
allowed to acquire MySQL, one of the commitments Oracle lawyer made was to
continue to develop *and release* MySQL version 6.0. I read the
almost-legally-binding statement, and thought yeah good luck with that!)


I wasn't involved in the active development, but possibly a similar example
could be the TPC architecture introduced in DSE 6.0. (A Cassandra derived
proprietary product that I worked on some time ago.) At least by the time I
was involved, I can't say that the performance resulting from that work
would have been a net positive to the full population of workloads. But
because it had been developed directly in the main 6.0 branch, and because
it is so invasive and core to everything else, it also wasn't possible to
roll back its introduction.

Finally, in an open source project, it's good to remember that we are all
volunteers here, in some sense, and sometimes it could happen that
development of a feature stops half way because its developer disappears
and nobody else picks it up.



So, returning back to this day and this database... Basically what you want
to avoid is to paint yourself into a corner, and particularly the wrong
corner. So the way I would answer this question is that large bodies of
work should:
 - Refactoring that is a) harmless, and/or b) improves the codebase anyway,
should be merged early into trunk.
 - The main body of the new functionality should be developed in a feature
branch up until some kind of MVP stage. This means that by the time it is
proposed for merge, a) it has been tested to both be of good quality and
that it actually provides the benefit it set out to implement. This means
that merging it to trunk will be a net improvement, always.
 - After that first big MVP merge, additional functionality of course could
be developed directly against trunk.
 - For patches that are very clean and self contained, for example in their
own Java package, it doesn't really matter, because they are easy to roll
back if needed. They can be developed against trunk.

So applying this to Josh's examples:

1) I assume JDK17 support is invasive, so that would suggest a feature
branch. However, the next question is, is there any risk involved in this
work (like Falcon for MySQL). Hypothetically it could be that Java 17 has
worse performance than Java 11, or some other blocking problem is
encountered. But in practice we probably estimate that this risk is small.
In such a case JDK17 support could indeed be developed with small patches
directly against trunk, but this would be an exception to the rule!

2) To take an example of an approved CEP, surprisingly enough, the
humongous Accord patch is actually very clean and self contained, and would
be easy to remove (or disable with a feature flag, which has been done). So
it could have been developed against trunk. (But I'm not sure that was
obvious in the beginning of development?)

3) The work on SSTable tries and Memtable tries was even explicitly split
into separate CEPs for the API 

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Berenguer Blasi]

Hi All,

I don't think we can be 100% prescriptive here. There will always be 
gray areas on where API changes start or end. Even on what is an API 
change and discussions about why a change was forgotten, not 
communicated, etc. I think we should rely on people's judgement on when 
to hit the ML/CEP when a significant change is about to come. Smaller 
changes could be caught by a weekly git digest of changes to a set of 
files, where any challenged commits should be easy to amend/revert 
within the week of the commit. What 'significant change', 'small 
change', etc means is left open to the criteria of the people involved 
and with time we will all align and learn.


Also would it be correct to assume it will be way way cheaper to address 
the seldom rare offenders than to CEP/ML every single change feeling the 
weight of the process? Think also on process burden for newcomers and 
the on boarding experience.


It doesn't 100% fit A, B or C but a bit from each.

On 2/2/23 17:54, Benedict wrote:
I’m inclined to agree with Jeremiah and Patrick, even if it might be a 
steep jump from what we’ve been used to. CQL needs to be treated with 
the utmost care and attention to detail. Would we apply the same 
standard to semantic bug fixes too? Perhaps we should, where there 
isn’t an urgent timeline at least.


Once the dust settles from this vote, depending how it tabulates, we 
can see what topics like this we might need another round to nail down.


On 2 Feb 2023, at 15:56, Jeremiah D Jordan 
 wrote:


 I think we need a DISCUSS thread at minimum for API changes.  And 
for anything changing CQL syntax, I think a CEP is warranted.  Even 
if it is only a small change to the syntax.



On Feb 2, 2023, at 9:32 AM, Patrick McFadin  wrote:

API changes are near and dear to my world. The scope of changes 
could be minor or major, so I think B is the right way forward.


Not to throw off the momentum, but could this even warrant a 
separate CEP in some cases? For example, CEP-15 is a huge change, 
but the CQL syntax will continuously evolve with more use. Being 
judicious in those changes is good for end users. It's also a good 
reference to point back to after the fact.


Patrick

On Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova 
 wrote:


“ Only that it locks out of the conversation anyone without a
Jira login”
Very valid point I forgot about - since recently people need
invitation in order to create account…
Then I would say C until we clarify the scope. Thanks

On Thu, 2 Feb 2023 at 8:54, Benedict  wrote:

I think lazy consensus is fine for all of these things. If a
DISCUSS thread is crickets, or just positive responses, then
definitely it can proceed without further ceremony.

I think “with heads-up to the mailing list” is very close to
B? Only that it locks out of the conversation anyone without
a Jira login.


On 2 Feb 2023, at 13:46, Ekaterina Dimitrova
 wrote:


While I do agree with you, I am thinking that if we include
many things that we would expect lazy consensus on I would
probably have different preference.

I definitely don’t mean to stall this though so in that case:
I’d say combination of A+C (jira with heads up on the ML if
someone is interested into the jira) and regular log on API
changes separate from CHANGES.txt or we can just add labels
to entries in CHANGES.txt as some other projects. (I guess
this is a detail we can agree on later on, how to implement
it, if we decide to move into that direction)

On Thu, 2 Feb 2023 at 8:12, Benedict 
wrote:

I think it’s fine to separate the systems from the
policy? We are agreeing a policy for systems we want to
make guarantees about to our users (regarding
maintenance and compatibility)

For me, this is (at minimum) CQL and virtual tables.
But I don’t think the policy differs based on the
contents of the list, and given how long this topic
stalled for. Given the primary point of contention
seems to be the *policy* and not the list, I think it’s
time to express our opinions numerically so we can move
the conversation forwards.

This isn’t binding, it just reifies the community
sentiment.


On 2 Feb 2023, at 13:02, Ekaterina Dimitrova
 wrote:


“ So we can close out this discussion, let’s assume
we’re only discussing any interfaces we want to make
promises for. We can have a separate discussion about
which those are if there is any disagreement.”
May I suggest we first clear this topic and then move
to voting? I would say I see confusion, not that much
of a disagreement. Should we raise a 

Re: CASSANDRA-14227 removing the 2038 limit

[Berenguer Blasi]

Hi,

20y is the current and historic value. 68y is what an integer can 
accommodate hence the current 2038 limit since the 1970 Unix epoch. I 
wouldn't make it a configurable value, off the top of my head it would 
make for some interesting bugs and debugging sessions when nodes had 
different values. Food for another ticket in any case imo.


Regards

On 3/2/23 14:18, Henrik Ingo wrote:

Naive PHB questions to follow...

Why are 68y and 20y special? Could you pick any value? Could we allow 
it to be configurable? (Last one probably overkill, just asking to 
understand...)


If we can pick any values we want, instinctively I would personally 
suggest to have TTL higher than 20 years, but also kicking the can 
further than 2035, which is only 13 years from now. Just to suggest a 
specific number, why not 35y and 2071?


henrik

On Fri, Feb 3, 2023 at 12:32 PM Berenguer Blasi 
 wrote:


Hi All,

a version using Uints, 20y max TTL and kicking the can down the
road until 2086 has been put up for review #justfyi

Regards

On 15/11/22 7:06, Berenguer Blasi wrote:


Hi all,

thanks for your answers!.

To Benedict's point: In terms of the uvint enconding of
deletionTime i.e. it is true it happens here

https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SerializationHeader.java#L170.
But we also have a DeletionTime serializer here

https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/DeletionTime.java#L166
that is writing an int and a long that would now write 2 longs.

TTL itself (the delta) remains an int in the new PR so it should
have no effect in size.

Did I reference the correct parts of the codebase? No sstable
expert here.

On 14/11/22 19:28, Josh McKenzie wrote:

in 2035 we'd hit the same problem again.

In terms of "kicking a can down the road", this would be a
pretty vigorous kick. I wouldn't push back against this deferral. :)

On Mon, Nov 14, 2022, at 9:28 AM, Benedict wrote:


I’m confused why we see *any* increase in sstable size - TTLs
and deletion times are already written as unsigned vints as
offsets from an sstable epoch for each value.

I would dig in more carefully to explore why you’re seeing this
increase? For the same data there should be no change to size
on disk.



On 14 Nov 2022, at 06:36, C. Scott Andreas
  wrote:
A 2-3% increase in storage volume is roughly equivalent to
giving up the gain from LZ4 -> LZ4HC, or a one to two-level
bump in Zstandard compression levels. This regression could be
very expensive for storage-bound use cases.

From the perspective of storage overhead, the unsigned int
approach sounds preferable.


On Nov 13, 2022, at 10:13 PM, Berenguer Blasi
 
wrote:


Hi all,

We have done some more research on c14227. The current patch
for CASSANDRA-14227 solves the TTL limit issue by switching
TTL to long instead of int. This approach does not have a
negative impact on memtable memory usage, as C* controles the
memory used by the Memtable, but based on our testing it
increases the bytes flushed by 4 to 7% and the byte on disk
by 2 to 3%.

As a mitigation to this problem it is possible to encode
/localDeletionTime/ as a vint. It results in a 1% improvement
but might cause additional computations during compaction or
some other operations.

Benedict's proposal to keep on using ints for TTL but as a
delta to nowInSecond would work for memtables but not for
work in the SSTable where nowInSecond does not exist. By
consequence we would still suffer from the impact on byte
flushed and bytes on disk.

Another approach that was suggested is the use of unsigned
integer. Java 8 has an unsigned integer API that would allow
us to use unsigned int for TTLs. Based on computation
unsigned ints would give us a maximum time of 136 years since
the Unix Epoch and therefore a maximum expiration timestamp
in 2106. We would have to keep TTL at 20y instead of 68y to
give us enough breathing room though, otherwise in 2035 we'd
hit the same problem again.

Happy to hear opinions.

On 18/10/22 10:56, Berenguer Blasi wrote:


Hi,

apologies for the late reply as I have been OOO. I have done
some profiling and results look virtually identical on trunk
and 14227. I have attached some screenshots to the ticket
https://issues.apache.org/jira/browse/CASSANDRA-14227.
Unless my eyes are fooling me everything in the jfrs look
the same.

Regards

On 30/9/22 9:44, Berenguer Blasi wrote:


Hi Benedict,

thanks for the reply! Yes some profiling is probably
needed, then we can see if going down the delta encoding
big refactor rabbit hole is worth it?

Let's see what other 

Re: [DISCUSS] Merging incremental feature work

[Andrés de la Peña]

Yes, I think that some refactors can also be directly merged if they have a
value for the end user on their own. Changes providing cleaner, better
documented and less tightly coupled code can have that value, even if they
aren't a new feature. Things like new APIs without an implementation
probably don't have that value.

I guess the criteria could be that partial CEP changes can be merged if
they would still make sense if there were a release the next day. Or, even
better, as if the next steps on the CEP were to never be completed.

On Fri, 3 Feb 2023 at 13:13, Josh McKenzie  wrote:

> The deeply coupled nature of some areas of our codebase does have some
> constraints it imposes on us here to your point. Without sensible internal
> APIs a lot of this type of work expands into two phases, one to refactor
> out said APIs and the other to introduce new functionality.
>
> It probably depends on what systems we’re extending or replacing and how
> tightly coupled the original design is as to which approach is feasible
> given resourcing.
>
> On Fri, Feb 3, 2023, at 7:48 AM, Sam Tunnicliffe wrote:
>
> This is quite timely as we're just gearing up to begin pushing the work
> we've been doing on CEP-21 into the public domain.
>
> This CEP is a slightly different from others that have gone before in that
> it touches almost every area of the system. This presents a few
> implementation challenges, most obviously around feature flagging and
> incremental merging. When we began prototyping and working on the design
> presented in CEP-21 it quickly became apparent that doing things
> incrementally would push an already large changeset into gargantuan
> proportions. Keeping changes isolated and abstracted would itself have
> required a vast amount of refactoring and rework of existing code and
> tests.
>
> I'll go into more detail in a CEP-21 specific mail shortly, but the plan
> we were hoping to follow was to work in a long lived topic branch, with
> JIRAs, sensible commit history and CI, and defer merging to trunk until the
> work as a whole is useable and meets all the existing bars for quality,
> review and the like.
>
>
> On 3 Feb 2023, at 12:43, Josh McKenzie  wrote:
>
> Anything we either a) have to do (JDK support) or b) have all agreed up
> front we think we should do (CEP). I.e. things with a lower risk of being
> left dead in the codebase partially implemented.
>
> I don't think it's a coincidence we've set up other processes to help
> de-risk and streamline the consensus building portion of this work given
> our history with it. We haven't taken steps to optimize the tactical
> execution of it yet.
>
> On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
>
> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
> >
> > My current thinking: I'd like to propose we all agree to move to merge
> work into trunk incrementally if it's either:
> > 1) New JDK support
> > 2) An approved CEP
>
> So basically everything?  I'm not sure what large complex bodies of
> work would be left.
>
>
>

Re: CASSANDRA-14227 removing the 2038 limit

[Henrik Ingo]

Naive PHB questions to follow...

Why are 68y and 20y special? Could you pick any value? Could we allow it to
be configurable? (Last one probably overkill, just asking to understand...)

If we can pick any values we want, instinctively I would personally suggest
to have TTL higher than 20 years, but also kicking the can further than
2035, which is only 13 years from now. Just to suggest a specific number,
why not 35y and 2071?

henrik

On Fri, Feb 3, 2023 at 12:32 PM Berenguer Blasi 
wrote:

> Hi All,
>
> a version using Uints, 20y max TTL and kicking the can down the road until
> 2086 has been put up for review #justfyi
>
> Regards
> On 15/11/22 7:06, Berenguer Blasi wrote:
>
> Hi all,
>
> thanks for your answers!.
>
> To Benedict's point: In terms of the uvint enconding of deletionTime i.e.
> it is true it happens here
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SerializationHeader.java#L170.
> But we also have a DeletionTime serializer here
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/DeletionTime.java#L166
> that is writing an int and a long that would now write 2 longs.
>
> TTL itself (the delta) remains an int in the new PR so it should have no
> effect in size.
>
> Did I reference the correct parts of the codebase? No sstable expert here.
> On 14/11/22 19:28, Josh McKenzie wrote:
>
> in 2035 we'd hit the same problem again.
>
> In terms of "kicking a can down the road", this would be a pretty vigorous
> kick. I wouldn't push back against this deferral. :)
>
> On Mon, Nov 14, 2022, at 9:28 AM, Benedict wrote:
>
>
> I’m confused why we see *any* increase in sstable size - TTLs and deletion
> times are already written as unsigned vints as offsets from an sstable
> epoch for each value.
>
> I would dig in more carefully to explore why you’re seeing this increase?
> For the same data there should be no change to size on disk.
>
>
> On 14 Nov 2022, at 06:36, C. Scott Andreas 
>  wrote:
>
> A 2-3% increase in storage volume is roughly equivalent to giving up the
> gain from LZ4 -> LZ4HC, or a one to two-level bump in Zstandard compression
> levels. This regression could be very expensive for storage-bound use cases.
>
> From the perspective of storage overhead, the unsigned int approach sounds
> preferable.
>
> On Nov 13, 2022, at 10:13 PM, Berenguer Blasi 
>  wrote:
>
> 
>
> Hi all,
>
> We have done some more research on c14227. The current patch for
> CASSANDRA-14227 solves the TTL limit issue by switching TTL to long instead
> of int. This approach does not have a negative impact on memtable memory
> usage, as C* controles the memory used by the Memtable, but based on our
> testing it increases the bytes flushed by 4 to 7% and the byte on disk by 2
> to 3%.
>
> As a mitigation to this problem it is possible to encode
> *localDeletionTime* as a vint. It results in a 1% improvement but might
> cause additional computations during compaction or some other operations.
>
> Benedict's proposal to keep on using ints for TTL but as a delta to
> nowInSecond would work for memtables but not for work in the SSTable where
> nowInSecond does not exist. By consequence we would still suffer from the
> impact on byte flushed and bytes on disk.
>
> Another approach that was suggested is the use of unsigned integer. Java 8
> has an unsigned integer API that would allow us to use unsigned int for
> TTLs. Based on computation unsigned ints would give us a maximum time of
> 136 years since the Unix Epoch and therefore a maximum expiration timestamp
> in 2106. We would have to keep TTL at 20y instead of 68y to give us enough
> breathing room though, otherwise in 2035 we'd hit the same problem again.
>
> Happy to hear opinions.
> On 18/10/22 10:56, Berenguer Blasi wrote:
>
> Hi,
>
> apologies for the late reply as I have been OOO. I have done some
> profiling and results look virtually identical on trunk and 14227. I have
> attached some screenshots to the ticket
> https://issues.apache.org/jira/browse/CASSANDRA-14227. Unless my eyes are
> fooling me everything in the jfrs look the same.
>
> Regards
> On 30/9/22 9:44, Berenguer Blasi wrote:
>
> Hi Benedict,
>
> thanks for the reply! Yes some profiling is probably needed, then we can
> see if going down the delta encoding big refactor rabbit hole is worth it?
>
> Let's see what other concerns people bring up.
>
> Thx.
> On 29/9/22 11:12, Benedict Elliott Smith wrote:
>
> My only slight concern with this approach is the additional memory
> pressure. Since 64yrs should be plenty at any moment in time, I wonder if
> it wouldn’t be better to represent these times as deltas from the nowInSec
> being used to process the query. So, long math would only be used to
> normalise the times to this nowInSec (from whatever is stored in the
> sstable) within a method, and ints would be stored in memtables and any
> objects used for processing.
>
> This might admittedly be more work, but I don’t believe it should 

Re: [DISCUSS] Merging incremental feature work

[Josh McKenzie]

The deeply coupled nature of some areas of our codebase does have some 
constraints it imposes on us here to your point. Without sensible internal APIs 
a lot of this type of work expands into two phases, one to refactor out said 
APIs and the other to introduce new functionality. 

It probably depends on what systems we’re extending or replacing and how 
tightly coupled the original design is as to which approach is feasible given 
resourcing.

On Fri, Feb 3, 2023, at 7:48 AM, Sam Tunnicliffe wrote:
> This is quite timely as we're just gearing up to begin pushing the work we've 
> been doing on CEP-21 into the public domain. 
> 
> This CEP is a slightly different from others that have gone before in that it 
> touches almost every area of the system. This presents a few implementation 
> challenges, most obviously around feature flagging and incremental merging. 
> When we began prototyping and working on the design presented in CEP-21 it 
> quickly became apparent that doing things incrementally would push an already 
> large changeset into gargantuan proportions. Keeping changes isolated and 
> abstracted would itself have required a vast amount of refactoring and rework 
> of existing code and tests. 
> 
> I'll go into more detail in a CEP-21 specific mail shortly, but the plan we 
> were hoping to follow was to work in a long lived topic branch, with JIRAs, 
> sensible commit history and CI, and defer merging to trunk until the work as 
> a whole is useable and meets all the existing bars for quality, review and 
> the like. 
> 
> 
>> On 3 Feb 2023, at 12:43, Josh McKenzie  wrote:
>> 
>> Anything we either a) have to do (JDK support) or b) have all agreed up 
>> front we think we should do (CEP). I.e. things with a lower risk of being 
>> left dead in the codebase partially implemented.
>> 
>> I don't think it's a coincidence we've set up other processes to help 
>> de-risk and streamline the consensus building portion of this work given our 
>> history with it. We haven't taken steps to optimize the tactical execution 
>> of it yet.
>> 
>> On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
>>> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
>>> >
>>> > My current thinking: I'd like to propose we all agree to move to merge 
>>> > work into trunk incrementally if it's either:
>>> > 1) New JDK support
>>> > 2) An approved CEP
>>> 
>>> So basically everything?  I'm not sure what large complex bodies of
>>> work would be left.

Re: [DISCUSS] Merging incremental feature work

[Andrés de la Peña]

I'm not sure a CEP is necessarily a big, complex piece of work that needs
to be split into multiple tickets. There could be single-ticket CEPs that
don't need multiple tickets, and still need the bureaucracy of a CEP due to
the impact of the change. However that probably isn't the common case.

Also, there could be complex CEPs with multiple steps that can be
incrementally merged to trunk because some of the steps have a value on
their own. For example, dynamic data masking (CEP-20) first creates CQL
functions for masking data, then it allows to attach those functions to the
schema, and then it allows to use UDFs as attached masking functions [1].
Each incremental step has a value on its own. For example, the first step
alone is what MySQL dynamic data masking consists on, just a bunch of
functions.

I think that CEP components that offer value on their own to the users can
perfectly be merged to trunk. That's because we could suddenly cut a
release including those changes and be happy with having included them.
However, if there are partial changes that don't give value to the end user
those changes should probably be in a feature branch. And the feature
branch could be merged every time it contains a releasable piece of work.
If the changes on that feature turn out to be massive, it could be a good
idea to create a separate ticket just for the merge, so reviewers can jump
at it and give a final pass with a global perspective.

[1]
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking#CEP20:DynamicDataMasking-Timeline

On Fri, 3 Feb 2023 at 12:48, Sam Tunnicliffe  wrote:

> This is quite timely as we're just gearing up to begin pushing the work
> we've been doing on CEP-21 into the public domain.
>
> This CEP is a slightly different from others that have gone before in that
> it touches almost every area of the system. This presents a few
> implementation challenges, most obviously around feature flagging and
> incremental merging. When we began prototyping and working on the design
> presented in CEP-21 it quickly became apparent that doing things
> incrementally would push an already large changeset into gargantuan
> proportions. Keeping changes isolated and abstracted would itself have
> required a vast amount of refactoring and rework of existing code and
> tests.
>
> I'll go into more detail in a CEP-21 specific mail shortly, but the plan
> we were hoping to follow was to work in a long lived topic branch, with
> JIRAs, sensible commit history and CI, and defer merging to trunk until the
> work as a whole is useable and meets all the existing bars for quality,
> review and the like.
>
>
> On 3 Feb 2023, at 12:43, Josh McKenzie  wrote:
>
> Anything we either a) have to do (JDK support) or b) have all agreed up
> front we think we should do (CEP). I.e. things with a lower risk of being
> left dead in the codebase partially implemented.
>
> I don't think it's a coincidence we've set up other processes to help
> de-risk and streamline the consensus building portion of this work given
> our history with it. We haven't taken steps to optimize the tactical
> execution of it yet.
>
> On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
>
> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
> >
> > My current thinking: I'd like to propose we all agree to move to merge
> work into trunk incrementally if it's either:
> > 1) New JDK support
> > 2) An approved CEP
>
> So basically everything?  I'm not sure what large complex bodies of
> work would be left.
>
>
>

Re: [DISCUSS] Merging incremental feature work

[Sam Tunnicliffe]

This is quite timely as we're just gearing up to begin pushing the work we've 
been doing on CEP-21 into the public domain. 

This CEP is a slightly different from others that have gone before in that it 
touches almost every area of the system. This presents a few implementation 
challenges, most obviously around feature flagging and incremental merging. 
When we began prototyping and working on the design presented in CEP-21 it 
quickly became apparent that doing things incrementally would push an already 
large changeset into gargantuan proportions. Keeping changes isolated and 
abstracted would itself have required a vast amount of refactoring and rework 
of existing code and tests. 

I'll go into more detail in a CEP-21 specific mail shortly, but the plan we 
were hoping to follow was to work in a long lived topic branch, with JIRAs, 
sensible commit history and CI, and defer merging to trunk until the work as a 
whole is useable and meets all the existing bars for quality, review and the 
like. 


> On 3 Feb 2023, at 12:43, Josh McKenzie  wrote:
> 
> Anything we either a) have to do (JDK support) or b) have all agreed up front 
> we think we should do (CEP). I.e. things with a lower risk of being left dead 
> in the codebase partially implemented.
> 
> I don't think it's a coincidence we've set up other processes to help de-risk 
> and streamline the consensus building portion of this work given our history 
> with it. We haven't taken steps to optimize the tactical execution of it yet.
> 
> On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
>> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie > > wrote:
>> >
>> > My current thinking: I'd like to propose we all agree to move to merge 
>> > work into trunk incrementally if it's either:
>> > 1) New JDK support
>> > 2) An approved CEP
>> 
>> So basically everything?  I'm not sure what large complex bodies of
>> work would be left.

Re: [DISCUSS] Merging incremental feature work

[Josh McKenzie]

Anything we either a) have to do (JDK support) or b) have all agreed up front 
we think we should do (CEP). I.e. things with a lower risk of being left dead 
in the codebase partially implemented.

I don't think it's a coincidence we've set up other processes to help de-risk 
and streamline the consensus building portion of this work given our history 
with it. We haven't taken steps to optimize the tactical execution of it yet.

On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
> >
> > My current thinking: I'd like to propose we all agree to move to merge work 
> > into trunk incrementally if it's either:
> > 1) New JDK support
> > 2) An approved CEP
> 
> So basically everything?  I'm not sure what large complex bodies of
> work would be left.
> 

Re: [DISCUSS] Merging incremental feature work

[Brandon Williams]

On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
>
> My current thinking: I'd like to propose we all agree to move to merge work 
> into trunk incrementally if it's either:
> 1) New JDK support
> 2) An approved CEP

So basically everything?  I'm not sure what large complex bodies of
work would be left.

[DISCUSS] Merging incremental feature work

[Josh McKenzie]

The topic of how we handle merging large complex bodies of work came up 
recently with the CEP-15 merge and JDK17, and we've faced this question in the 
past as well (CASSANDRA-8099 comes to mind).

The times we've done large bodies of work separately from trunk and then merged 
them in have their own benefits and costs, and the examples I can think of 
where we've merged in work to trunk incrementally with something flagged 
experimental have markedly different cost/benefits. Further, the two approaches 
have shaped the *way* we approached work quite differently with how we 
architected and tested things.

My current thinking: I'd like to propose we all agree to move to merge work 
into trunk incrementally if it's either:
1) New JDK support
2) An approved CEP

The bar for merging anything into trunk should remain:
1) 2 +1's from committers
2) Green CI (presently circle or ASF, in the future ideally ASF or an ASF 
analog env)

I don't know if this is a generally held opinion and we just haven't discussed 
it and switched our general behavior yet, or if this is more controversial, so 
I won't burden this email with enumerating pros and cons of the two approaches 
until I get a gauge of the community's temperature.

So - what do we think?

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[Andrés de la Peña]

I think removing the need for ALLOW FILTERING on virtual tables makes sense
and would be quite useful for operators.

That guard exists for performance issues that shouldn't occur on virtual
tables. We also have a flag in case some future virtual table
implementation has limitations regarding filtering, although it seems it's
not the case with any of the existing virtual tables.

It is not like we would promote bad habits because virtual tables are meant
to be queried by operators / administrators only.


It might even be quite the opposite, since in the current situation users
might get used to routinely use ALLOW FILTERING for querying their virtual
tables.

It has been mentioned on the #cassandra-dev Slack thread where this started
(1) that it's kind of an API inconsistency to allow querying by non-primary
keys on virtual tables without ALLOW FILTERING, whereas it's required for
regular tables. I think that a simply doc update saying that virtual
tables, which are not regular tables, support filtering would be enough.
Virtual tables are well identified by both the keyspace they belong to and
doc, so users shouldn't have trouble knowing whether a table is virtual. It
would be similar to the current exception for ALLOW FILTERING, where one
needs to use it unless the table has an index for the queried column.

(1) https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329

On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi list,
>
> the content of virtual tables is held in memory (and / or is fetched every
> time upon request). While doing queries against such table for a column
> outside of primary key, normally, users are required to specify ALLOW
> FILTERING. This makes total sense for "ordinary tables" for applications to
> have performant and effective queries but it kinds of loses the
> applicability for virtual tables when it literally holds just handful of
> entries in memory and it just does not matter, does it?
>
> What do you think about implicitly allowing filtering for virtual tables
> so we save ourselves from these pesky errors when we want to query
> arbitrary column and we need to satisfy CQL spec just to do that?
>
> It is not like we would promote bad habits because virtual tables are
> meant to be queried by operators / administrators only.
>
> We can also explicitly document this behavior.
>
> Among other options, we may try to implement secondary indices on virtual
> tables but I am not completely sure this is what we want because its
> complexity etc. Is it even necessary to put such complex logic in place
> just to be able to select any column on few entries in memory?
>
> I put together a draft here (1). It would be ever possible to implicitly
> allow filtering on virtual tables only and it would be implementator's
> responsibility to decide that, per table.
>
> For all virtual tables we currently have, I would enable this everywhere.
> I do not think there is any virtual table where we would not want to enable
> it or where people HAVE TO specify that.
>
> (1) https://github.com/apache/cassandra/pull/2131

Re: Introducing mockito-inline library among test dependencies

[Miklosovic, Stefan]

Hi list,

I forgot to update this thread. I just want to let you know that since we 
merged CASSANDRA-14361 to trunk which introduced mockito-inline dependency, you 
can mock static methods in trunk already.

Regards


From: Miklosovic, Stefan 
Sent: Thursday, January 12, 2023 14:59
To: dev@cassandra.apache.org
Subject: Re: Introducing mockito-inline library among test dependencies

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.




Hi Jacek,

that is very good question, I will try to get back to you with the answer.

Also, just before merging 14361, we noticed that we are also hitting some 
issues on mocking stuff in 
org.apache.cassandra.distributed.mock.nodetool.InternalNodeProbe which failed 
some other tests.

I remember that I wanted to mock static methods like two years ago and I hit 
the very same issue back then as I do now (1).

Please keep in mind that the error is not related to what I wanted to test for 
CASSANDRA-14361, it is rather the consequence of us including mockito-inline to 
mock static methods and as we included it into the build and run full CI, the 
completely unrelated tests started to fail because of that. This issue seems to 
be in Mockito from times of 3.x and they are still present in 4.7.0.

I was able to workaround this issue in Cassandra code. The path towards using 
static mocks is not so straightforward but should be possible with a little bit 
more love. (2)

(1) https://github.com/mockito/mockito/issues/2203
(2) https://issues.apache.org/jira/browse/CASSANDRA-18152


From: Jacek Lewandowski 
Sent: Thursday, January 12, 2023 13:21
To: dev@cassandra.apache.org
Subject: Re: Introducing mockito-inline library among test dependencies

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.



Will it work with Java17?

czw., 12 sty 2023, 12:56 użytkownik Brandon Williams 
mailto:dri...@gmail.com>> napisał:
+1

Kind Regards,
Brandon

On Wed, Jan 11, 2023 at 2:02 PM Miklosovic, Stefan
mailto:stefan.mikloso...@netapp.com>> wrote:
>
> Hi list,
>
> the test for (1) is using mockito-inline dependency for mocking static 
> methods as mockito-core is not able to do that on its own. mockito-inline was 
> not part of our test dependencies prior this work. I want to ask if we are 
> all OK with being able to mock static methods from now on with the help of 
> this library.
>
> Please tell me if we are mocking static methods already by some other (to me 
> yet unknown) mean so we do not include this unnecessarily.
>
> G:A:V is org.mockito:mockito-inline:4.7.0
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-14361
>
> Thanks

Re: CASSANDRA-14227 removing the 2038 limit

[Berenguer Blasi]

Hi All,

a version using Uints, 20y max TTL and kicking the can down the road 
until 2086 has been put up for review #justfyi


Regards

On 15/11/22 7:06, Berenguer Blasi wrote:


Hi all,

thanks for your answers!.

To Benedict's point: In terms of the uvint enconding of deletionTime 
i.e. it is true it happens here 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SerializationHeader.java#L170. 
But we also have a DeletionTime serializer here 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/DeletionTime.java#L166 
that is writing an int and a long that would now write 2 longs.


TTL itself (the delta) remains an int in the new PR so it should have 
no effect in size.


Did I reference the correct parts of the codebase? No sstable expert here.

On 14/11/22 19:28, Josh McKenzie wrote:

in 2035 we'd hit the same problem again.
In terms of "kicking a can down the road", this would be a pretty 
vigorous kick. I wouldn't push back against this deferral. :)


On Mon, Nov 14, 2022, at 9:28 AM, Benedict wrote:


I’m confused why we see *any* increase in sstable size - TTLs and 
deletion times are already written as unsigned vints as offsets from 
an sstable epoch for each value.


I would dig in more carefully to explore why you’re seeing this 
increase? For the same data there should be no change to size on disk.



On 14 Nov 2022, at 06:36, C. Scott Andreas  
wrote:
A 2-3% increase in storage volume is roughly equivalent to giving 
up the gain from LZ4 -> LZ4HC, or a one to two-level bump in 
Zstandard compression levels. This regression could be very 
expensive for storage-bound use cases.


From the perspective of storage overhead, the unsigned int approach 
sounds preferable.


On Nov 13, 2022, at 10:13 PM, Berenguer Blasi 
 wrote:



Hi all,

We have done some more research on c14227. The current patch for 
CASSANDRA-14227 solves the TTL limit issue by switching TTL to 
long instead of int. This approach does not have a negative impact 
on memtable memory usage, as C* controles the memory used by the 
Memtable, but based on our testing it increases the bytes flushed 
by 4 to 7% and the byte on disk by 2 to 3%.


As a mitigation to this problem it is possible to encode 
/localDeletionTime/ as a vint. It results in a 1% improvement but 
might cause additional computations during compaction or some 
other operations.


Benedict's proposal to keep on using ints for TTL but as a delta 
to nowInSecond would work for memtables but not for work in the 
SSTable where nowInSecond does not exist. By consequence we would 
still suffer from the impact on byte flushed and bytes on disk.


Another approach that was suggested is the use of unsigned 
integer. Java 8 has an unsigned integer API that would allow us to 
use unsigned int for TTLs. Based on computation unsigned ints 
would give us a maximum time of 136 years since the Unix Epoch and 
therefore a maximum expiration timestamp in 2106. We would have to 
keep TTL at 20y instead of 68y to give us enough breathing room 
though, otherwise in 2035 we'd hit the same problem again.


Happy to hear opinions.

On 18/10/22 10:56, Berenguer Blasi wrote:


Hi,

apologies for the late reply as I have been OOO. I have done some 
profiling and results look virtually identical on trunk and 
14227. I have attached some screenshots to the ticket 
https://issues.apache.org/jira/browse/CASSANDRA-14227 
. Unless 
my eyes are fooling me everything in the jfrs look the same.


Regards

On 30/9/22 9:44, Berenguer Blasi wrote:


Hi Benedict,

thanks for the reply! Yes some profiling is probably needed, 
then we can see if going down the delta encoding big refactor 
rabbit hole is worth it?


Let's see what other concerns people bring up.

Thx.

On 29/9/22 11:12, Benedict Elliott Smith wrote:
My only slight concern with this approach is the additional 
memory pressure. Since 64yrs should be plenty at any moment in 
time, I wonder if it wouldn’t be better to represent these 
times as deltas from the nowInSec being used to process the 
query. So, long math would only be used to normalise the times 
to this nowInSec (from whatever is stored in the sstable) 
within a method, and ints would be stored in memtables and any 
objects used for processing.


This might admittedly be more work, but I don’t believe it 
should be too challenging - we can introduce a method 
deletionTime(int nowInSec) that returns a long value by adding 
nowInSec to the deletionTime, and make the underlying value 
private, refactoring call sites?


On 29 Sep 2022, at 09:37, Berenguer Blasi 
  
wrote:


Hi all,

I have taken a stab in a PR you can find attached in the 
ticket. Mainly:


- I have moved deletion times, gc and nowInSec timestamps to 
long. That should get us past the 2038 limit.


- TTL is maxed now to 68y. Think CQL API compatibility and a 
sort of a 

Implicitly enabling ALLOW FILTERING on virtual tables

[Miklosovic, Stefan]

Hi list,

the content of virtual tables is held in memory (and / or is fetched every time 
upon request). While doing queries against such table for a column outside of 
primary key, normally, users are required to specify ALLOW FILTERING. This 
makes total sense for "ordinary tables" for applications to have performant and 
effective queries but it kinds of loses the applicability for virtual tables 
when it literally holds just handful of entries in memory and it just does not 
matter, does it?

What do you think about implicitly allowing filtering for virtual tables so we 
save ourselves from these pesky errors when we want to query arbitrary column 
and we need to satisfy CQL spec just to do that?

It is not like we would promote bad habits because virtual tables are meant to 
be queried by operators / administrators only.

We can also explicitly document this behavior.

Among other options, we may try to implement secondary indices on virtual 
tables but I am not completely sure this is what we want because its complexity 
etc. Is it even necessary to put such complex logic in place just to be able to 
select any column on few entries in memory?

I put together a draft here (1). It would be ever possible to implicitly allow 
filtering on virtual tables only and it would be implementator's responsibility 
to decide that, per table.

For all virtual tables we currently have, I would enable this everywhere. I do 
not think there is any virtual table where we would not want to enable it or 
where people HAVE TO specify that.

(1) https://github.com/apache/cassandra/pull/2131