I am done, the ticket needs another committer though.
On Fri, Jul 26, 2024 at 7:00 PM Josh McKenzie wrote:
> +1 to should block as well.
>
> On Fri, Jul 26, 2024, at 12:15 PM, Patrick McFadin wrote:
>
> This is a weird regression but I'm borderline on this being a blocker. On
> a brand new node
Understood. Nits aside I have no objection to your plan.
Jordan
On Tue, Jul 30, 2024 at 15:42 Caleb Rackliffe
wrote:
> I think the main motivation for ignoring the YAML option and removing
> down the line is that we probably never would have created it if TCM
> existed at that point of creation
I think the main motivation for ignoring the YAML option and removing
down the line is that we probably never would have created it if TCM
existed at that point of creation. I'd liken it to what we did w/ some
no-longer-relevant options for the batch commit log.
On Tue, Jul 30, 2024 at 5:19 PM Jor
Generally no disagreement but more of a curiosity: what’s the motivation
for removal? Just that it’s not needed? Otherwise it’s relatively cheap and
DDL aren’t high throughput (or at least shouldn’t be since we can only deal
with so many tables)
Jordan
On Tue, Jul 30, 2024 at 15:04 Caleb Rackliff
To summarize all this noise I've created, the plan would be...
1.) Leave CQL WITH id intact.
2.) Deprecate and WARN on *use_deterministic_table_id *in 5.0.x.
3.) Ignore and WARN on *use_deterministic_table_id *in 5.1.
4.) Profit
On Tue, Jul 30, 2024 at 4:46 PM Caleb Rackliffe
wrote:
> No intent
No intention of touching WITH id in CQL
On Tue, Jul 30, 2024 at 4:10 PM Caleb Rackliffe
wrote:
> To clarify, my plan was to deprecate in Config/JMX and ignore it, not
> remove it entirely so it breaks existing YAMLs and JMX clients.
>
> This should be fine, if I'm reading the upgrade notes corre
To clarify, my plan was to deprecate in Config/JMX and ignore it, not
remove it entirely so it breaks existing YAMLs and JMX clients.
This should be fine, if I'm reading the upgrade notes correctly, as no
table or view creation operations will be allowed on 5.1 nodes until
upgrade is complete and
+1 to deprecate it. What does removing it buy us?
> On Jul 30, 2024, at 3:52 PM, David Capwell wrote:
>
> Users can provide ids and TCM can manage to make them safe, so agree we
> don’t really need the feature anymore. I am fine with deprecating the
> feature, but removing would be a breakin
Users can provide ids and TCM can manage to make them safe, so agree we don’t
really need the feature anymore. I am fine with deprecating the feature, but
removing would be a breaking change for anyone that had that config in place,
so not a fan of breaking the config interface.
> On Jul 30, 2
I'd like to propose removing deterministic table IDs for new *user* tables
and views in trunk. With TCM in place, it looks like the reason we added
*use_deterministic_table_id*, concurrent table creations, is no longer a
concern.
Thoughts? Objections?
reply below.
We're moving into a world where we will likely more frequently modify the
> mainline branch with new functionality to integrate with ecosystem changes
> (sidecar, analytics, drivers?). It's probably at least worth a conversation
> as to whether our current policy (improvements and ne
Any change we bring to stable releases, even though it is non-user facing
change, brings in the possibility of introducing bugs and / or unintended
side effects. Therefore it is important to carefully consider the trade
offs when we make changes to older releases. We also have a precedent to
make c
I would make the case that loss of availability / significant performance
issue, regardless of the amount of time it has existed for, is worth fixing
on the branches that are widely deployed by the community. Especially when
weighed against a loosely defined public interface issue.
The queuing iss
Why does the age of the issue matter when it affects availability?
On Tue, Jul 30, 2024 at 10:30 AM Jeff Jirsa wrote:
>
> It’s a 10 year old flaw in an 18 month old branch. Why does it need to go
> into 4.1, it’s not a regression and it clearly breaks compatibility?
>
>
>
>
> On Jul 30, 2024, at
It’s a 10 year old flaw in an 18 month old branch. Why does it need to go into
4.1, it’s not a regression and it clearly breaks compatibility?
> On Jul 30, 2024, at 8:52 AM, Jon Haddad wrote:
>
> This patch fixes a long standing issue that's the root cause of availability
> failures. Eve
I think I would prefer to not introduce the change I have proposed (the one
that would bring back non-binary compatibility). I will wait a bit to see what
other folks in the community think, but if we could just have a release note
that anyone who happens to have their own custom query handler c
Here is my 2 cents. Maybe we need to differentiate the user-facing
improvements and ecosystem-internal improvements, or have a discussion
about it.
I guess when the current policy of "improvements and new features on trunk
only" was made, it was to target the user-facing improvements. The internal
If there is a quick fix for the interface issue as Alex is describing then
I am all for it. I think binary compatibility isn’t required here so the
compile time compat would be good enough.
Otherwise I tend to agree that while it should be considered a public
interface we haven’t had a strict defi
I know of a few custom tracing implementations that implement a custom query handler to work. No clue how maintained they still are.The elassandra project uses the custom query handler.DataStax uses the customer query handler for DSE (we maintain our own forks now, so can work around what ever hap
This patch fixes a long standing issue that's the root cause of
availability failures. Even though folks can specify a custom query
handler with the -D flag, the number of users impacted by this is going to
be incredibly small. On the other hand, the fix helps every single user of
4.1 that puts t
Right, we do have "custom_query_handler_class". I was under impression it was
used for testing, but checked the history, and it was around for a while, so it
might have been used outside tests too.
In this case we have 2 options:
* to convert the new method in the interface to a "default" meth
Given we allow a pluggable query handler implementation to be specified for the server with a -D during startup. So I would consider the query handler one of our public interfaces.On Jul 30, 2024, at 9:35 AM, Alex Petrov wrote:Hi Tommy,Thank you for spotting this and bringing this to community's
Hi Tommy,
Thank you for spotting this and bringing this to community's attention.
I believe our primary interfaces are native and internode protocol, and CLI
tools. Most interfaces are used to to abstract implementations internally. Few
interfaces, such as DataType, Partitioner, and Triggers ca
Some thoughts:
1. Most of our PMC votes are majority-based, not binding -1. So Jeff being -1
doesn't mean the whole PMC being -1. So don't take his -1 as being a show
stopper or indicative of everyone on the PMC (and don't take me saying this as
the converse ;))
2. I expect we have a lot of de
Hi,
There is a change in the QueryHandler interface introduced by
https://issues.apache.org/jira/browse/CASSANDRA-19534
Do we allow changes such changes between 4.1.5 and 4.1.6?
CASSANDRA-19534 looks like a very good change so maybe there is an exception in
this case?
/Tommy
-Original Mes
25 matches
Mail list logo
