[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216958#comment-17216958 ] Jordan West commented on CASSANDRA-16048: - Thanks [~marcuse]. Addressed all comments and added the flag. My concern was what it meant to opt-in then opt-out but I think its minimal in reality. I made it a start-up flag since changing it at runtime wouldn't have meaning. > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216490#comment-17216490 ] Marcus Eriksson commented on CASSANDRA-16048: - Added a few nits on the commit, and, as Caleb and Sylvain mentioned, having some logging around this would be good. bq. I skipped adding a flag since we can't detect and "undo" updating the tables that were updated. Could you expand on this? Not sure I follow - sounds like having the flag would be better? > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215155#comment-17215155
]
Jordan West commented on CASSANDRA-16048:
-
Updated the branch to address [~marcuse]'s comment re: updated the flags in
{{system_schema.tables}}. Had to move things around to account for the changes
in CASSANDRA-16063. Updated the test as well.
I skipped adding a flag since we can't detect and "undo" updating the tables
that were updated. If folks feel strongly about the flag I can add it.
Branch: https://github.com/apache/cassandra/compare/trunk...jrwest:jwest/16048
Tests:
https://app.circleci.com/pipelines/github/jrwest/cassandra?branch=jwest%2F16048
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204558#comment-17204558
]
Marcus Eriksson commented on CASSANDRA-16048:
-
We should probably make sure that flags in {{system_schema.tables}} matches
what we have in-memory, to make sure that clients have a correct view of the
table (they probably don't do anything different in this case, but anyway).
Currently it only gets saved on the next ALTER to that table.
Would it also make sense to hide this behind a flag (start with
{{-Dcassandra.allow_ignore_compact_storage}} or something)?
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200944#comment-17200944 ] Caleb Rackliffe commented on CASSANDRA-16048: - [~jwest] Dropped a couple more minor nits (mostly agreeing w/ Sylvain that some logging wouldn't hurt), but otherwise, LGTM +1 > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197025#comment-17197025 ] Jordan West commented on CASSANDRA-16048: - [~ifesdjeen] thanks! I see the extra step necessary to produce the difference (my test basically validates the row is still gone but doesn't test subsequent deletes). I'll have to think about that in the context of this change a bit more. The test in the branch and the one I linked also shows its safe (excluding this delete case I need to dig into more) to have mixed schema (during agreement). > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196777#comment-17196777
]
Alex Petrov commented on CASSANDRA-16048:
-
[~jwest] missed your comment about Harry. We do have Harry for this; and it
would correctly find this inconsistency. However, schema changes are not
propagated throughout the cluster in a deterministic way, so we'd have to
accept both responses until we can guarantee that {{DROP COMPACT STORAGE}} has
propagated. For now, I think, the best way to proceed with this would be to
populate a table, drop compact storage, wait for schema convergence, and
re-validate it with a new schema. But in the future we'll definitely have some
better support for schema changes.
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196772#comment-17196772
]
Alex Petrov commented on CASSANDRA-16048:
-
[~jwest] sure, here's the repro:
Setup:
{code:java}
cqlsh> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> CREATE TABLE test.test_comact_storage (pk int, ck int, v1 int, primary
key (pk, ck)) WITH COMPACT STORAGE;
cqlsh> CREATE TABLE test.test_not_comact_storage (pk int, ck int, v1 int,
primary key (pk, ck));
{code}
Populate both tables with a single row:
{code:java}
cqlsh> INSERT INTO test.test_comact_storage (pk, ck, v1) VALUES (1,1,1);
cqlsh> INSERT INTO test.test_not_comact_storage (pk, ck, v1) VALUES (1,1,1);
cqlsh> select * from test.test_comact_storage;
pk | ck | v1
++
1 | 1 | 1
(1 rows)
cqlsh> select * from test.test_not_comact_storage;
pk | ck | v1
++
1 | 1 | 1
(1 rows)
{code}
Both tables return the same result (as their schemas are visibly identical).
Now, try deleting v1 value from the row:
{code:java}
cqlsh> DELETE v1 FROM test.test_comact_storage WHERE pk = 1 AND ck = 1;
cqlsh> DELETE v1 FROM test.test_not_comact_storage WHERE pk = 1 AND ck = 1;
cqlsh> select * from test.test_comact_storage;
pk | ck | v1
++
(0 rows)
cqlsh> select * from test.test_not_comact_storage;
pk | ck | v1
++--
1 | 1 | null
(1 rows)
{code}
As you see, in a compact storage table we have removed an entire row, but in a
regular table we, as you'd expect, have removed just {{v1}}
Now, drop comact storage from the table:
{code:java}
cqlsh> alter table test.test_comact_storage DROP COMPACT STORAGE;
cqlsh> select * from test.test_comact_storage;
pk | ck | v1
++
(0 rows)
{code}
Row is still not visible, but that's ok, otherwise it'd probably be worse.
However, starting now, behaviour of {{DELETE v1}} is going to change on this
table:
{code:java}
cqlsh> INSERT INTO test.test_comact_storage (pk, ck, v1) VALUES (2,2,2);
cqlsh> DELETE v1 FROM test.test_comact_storage WHERE pk = 2 AND ck = 2;
cqlsh> select * from test.test_comact_storage;
pk | ck | v1
++--
2 | 2 | null
{code}
Previously, we would see an entire row hidden. Now we won't.
I'm not saying this is something huge, maybe there's even no use-case for
something like this, but I thought it's important to point this out.
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194524#comment-17194524 ] Jordan West commented on CASSANDRA-16048: - [~ifesdjeen] do you have a repro of that? I added some column level deletes in a [test I added previously | https://github.com/apache/cassandra/blob/cassandra-3.0/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage2to3UpgradeTest.java#L190] and it didn't source any issues. Admittedly, it could be more robust and there may be a case I missed (aside: it would be nice to have Harry for this), but if you have a repro to share that would be super helpful. Thanks! > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > -- > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182991#comment-17182991
]
Alex Petrov commented on CASSANDRA-16048:
-
I'd like to point out that while there's no visible change to the user facing
schema after dropping compact storage, there's a difference in {{DELETE
}} behaviour: table with compact storage will not show a row that has
all values in regular columns deleted. Maybe this distincion is not big enough
for us not to consider silently dropping compact storage, but it might be
important for some applications.
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181410#comment-17181410
]
Jordan West commented on CASSANDRA-16048:
-
{quote}this has user visible consequences (no more "WITH COMPACT STORAGE"
mention when using DESCRIBED and removed DENSE flag), even if they can arguably
be considered minor.{/quote}.
Agreed. I should have been more specific that I was referring to visible
changes to query results as shown by the included test.
{quote}Without this patch, users are obligated to manually run DROP COMPACT
STORAGE on all tables, so no risk of surprise exists. Which is kind of a
feature in that case imo.{quote}
In practice, I am finding this to not be the case. Instead, its a blocker to
upgrading that will cause a significant burden and time commitment including
user outreach, etc.
{quote} to ask a few power users to run more manual DROP COMPACT STORAGE (it's
not like it can't be scripted externally easily if you know what you're doing)
{quote}
This is an option I explored as well. While the scripting might be easy, the
risk to organizations doing so is more complex. It also requires identifying
the types of tables that are safe to call {{DROP COMPACT STORAGE}} on vs the
ones that will necessarily result in a user visible query result change like
this patch does. That can be done in the script but I've found it more
straightforward to implement and test w/in the database as done in this patch.
I'll take a look at CASSANDRA-16063. Thanks.
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181308#comment-17181308
]
Sylvain Lebresne commented on CASSANDRA-16048:
--
bq. Regarding the DENSE flag, this is the same as if "DROP COMPACT STORAGE" was
run, and the behavior prior to this patch is that the database would fail to
start, so I'm not sure there will be much surprise to the user or that its of
much concern.
This patch silently drop compact storage on (some) user tables. And as
mentionned, this _has_ user visible consequences (no more "WITH COMPACT
STORAGE" mention when using {{DESCRIBED}} and removed {{DENSE}} flag), even if
they can arguably be considered minor.
The user surprise I'm talking about is a user noticing one of those
consequences some time post 4.0 upgrade, and having no clue why this happened
(since again, the drop is automatic and basically silent\[1\]). I mean, in
general, silent changes tends to be surprising.
Without this patch, users are obligated to _manually_ run {{DROP COMPACT
STORAGE}} on all tables, so no risk of surprise exists. Which is kind of a
feature in that case imo.
I suppose the opinion I'm pushing here is that it might be better to ask a few
power users to run more manual {{DROP COMPACT STORAGE}} (it's not like it can't
be scripted externally easily if you know what you're doing), than risking to
confuse some users, even slightly, around something already kind of confusing
like compact tables. Obviously, I don't know how many and how much users might
get confused by this. And probably not a lot. Is the risk worth the upside for
users in general? I lean "no" as of now, but definitively a very weakly held
position.
bq. As an aside, I am also concerned about the current behavior that we halt
the database from starting when we detect compact storage tables
This may or may not be what you meant here, but fwiw, I created CASSANDRA-16063
which is relevant (long story short, I think the general behavior is sensible
but I don't think it's implemented right; if you're concerned by the general
behavior and have alternative to propose, feel free to hijack that ticket for
that purpose).
\[1\]: on that "silent" subject: I think that if we do end up doing this, we
should at least clearly log when we automatically migrating a table, which the
current patch don't do, so it's not completely silent. Tbc, doing so wouldn't
entirely assuage my concerns because I don't think everyone reads their log
carefully.
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180022#comment-17180022
]
Jordan West commented on CASSANDRA-16048:
-
Thanks for the input [~slebresne]. I was hoping you would chime in.
I'm currently working on a plan for migrating a rather large fleet off of
{{COMPACT STORAGE}} and found this approach to reduce the burden significantly
(my findings are that the "shape" of COMPACT STORAGE table addressed by this
patch is very common). Each additional out of band process that needs to be
performed before the upgrade adds to the burden of moving to 4.0 and having a
safe way that operators don't have to think about is helpful. However, I do
agree its unfortunate we can't do this for all COMPACT STORAGE tables so that
we have a unified story and I am +1 on the documentation reading something like
to "you should drop COMPACT STORAGE manually by yourself before upgrading to
4.0 -- see CASSANDRA-16048 for potential alternatives".
Regarding the DENSE flag, this is the same as if "DROP COMPACT STORAGE" was
run, and the behavior prior to this patch is that the database would fail to
start, so I'm not sure there will be much surprise to the user or that its of
much concern. I did consider putting the patch behind a flag that defaulted to
off but the semantics of flipping that flag sometime after the upgrade are even
more confusing imo.
As an aside, I am also concerned about the current behavior that we halt the
database from starting when we detect compact storage tables but I need to
investigate more what escape hatches exist before filing anything.
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16048) Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and Value Columns
[
https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179691#comment-17179691
]
Sylvain Lebresne commented on CASSANDRA-16048:
--
Not to reject this upfront completely, but wanted to note that a part of me
wonders if this is a good idea.
First, I feel this murky the waters a bit around the upgrade path to 4.0. "You
have to run {{DROP COMPACT STORAGE}} on all compact table before upgrading" is
a simple rule. Simple is good, and I feel adding special cases is adding
confusion. And the upside here is pretty minor.
Of course, we could leave this undocumented, and keep only the simple rule in
all documentation. But if we don't document this, I think this create a risk of
surprising users, which is my other point.
Because it's not 100% true that "there is no visible change to the user facing
schema after dropping compact storage". The schema of those tables loses the
{{WITH COMPACT STORAGE}} (and the {{system_schema}} table will lose the
{{DENSE}} flag, which is also technically visible). Which may sound trivial,
but it's a bit hard to ensure that there no user tool/code out there that rely
on it. And in general, users may simply be confused that their table appears to
lose a property silently, or wonder why the schema dump of that table done on
3.x does not replay properly on 4.0 anymore.
Tbc, I get how for "us", devs of C* that understand the internals, it sounds
annoying to have to run a command when we know it could be done automatically
and we're not gonna be confused by it. Just not sure this is a good place to
optimize for "us".
> Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and
> Value Columns
> --
>
> Key: CASSANDRA-16048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16048
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Some compact storage tables, specifically those where the user has defined
> both at least one clustering and the value column, can be safely handled in
> 4.0 because besides the DENSE flag they are not materially different post 3.0
> and there is no visible change to the user facing schema after dropping
> compact storage. We can detect this case and allow these tables to silently
> drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE
> tables that don’t meet the criteria.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
