No actual removal would be done. All would stay as it is, it would just
call SnapshotMangers's stuff where appropriate. SnapshotManager(MBean)
would be introduced to centralize snapshots' logic. By deprecation, I meant
that we would put "@Deprecated" annotation on StorageServiceMBean methods
as it
Woah, I didn't even notice its removal. Just read through CASSANDRA-18959
to get caught up. Thanks for the correction.
Let's wave away that point then. If we're looking at a multi-year
deprecation process does anyone else feel the UX of discovering the
snapshot method on the table in JConsole h
On Thu, Aug 1, 2024 at 9:22 AM Jon Haddad wrote:
> I don't think we've deprecated or removed anything that mentions "column
> family" or "cf" even though that hasn't been our user-facing terminology in
> close to a decade. Please correct me if I'm wrong on any of this.
Off the top of my head
I would prefer we kept the old methods in place without deprecation.
* I (and I assume others) learn about what I can do with JMX by using
JConsole and browsing visually, and find it helpful to be able to look at a
table and understand what I can do with it. Approaching it the other way
isn't par
Hi,
First, thanks everyone for considering this. I did not expect such a big
discussion form this, for me it was not such a big thing and a think
CASSANDRA-19534 is a very good improvement.
If I have to recompile I would also update the code so I'm not sure I see much
benefit with compile time
@Tommy do you think? You brought the issue up, I am assuming because you found the issue while trying to test ecaudit against the proposed release and it broke the integration? As an active consumer of the interface what are your thoughts?On Aug 1, 2024, at 8:17 AM, Alex Petrov wrote:> If we hav
> If we have a path that resolves the issue and also maintains full
> compatibility for this (semi- / reluctantly-accessible) interface, that would
> seem ideal. Interested to learn more about the drawbacks to that approach.
My thinking here was that people who might have a binary dependency on
Sorry to derail the discussion but just on a point of order, there is actually
precedent for requiring a minimum patch level before a major upgrade. For
instance, from NEWS.txt:
Upgrade to 3.0 is supported from Cassandra 2.1 versions greater or
equal to 2.1.9, or Cassandra 2.2 version
We are refactoring the snapshotting subsystem (CASSANDRA-18111) by
consolidating all snapshot logic in Cassandra code into a dedicated
SnapshotManager class where everything is centralized and dandy.
The current state of snapshotting code is that over the years it became
scattered all over the pla
