adelapena commented on code in PR #2110:
URL: https://github.com/apache/cassandra/pull/2110#discussion_r1114679461
##########
src/java/org/apache/cassandra/schema/SchemaKeyspace.java:
##########
@@ -688,15 +695,58 @@ private static void
addColumnToSchemaMutation(TableMetadata table, ColumnMetadat
{
AbstractType<?> type = column.type;
if (type instanceof ReversedType)
- type = ((ReversedType) type).baseType;
+ type = ((ReversedType<?>) type).baseType;
- builder.update(Columns)
+ Row.SimpleBuilder rowBuilder = builder.update(Columns)
.row(table.name, column.name.toString())
.add("column_name_bytes", column.name.bytes)
.add("kind", column.kind.toString().toLowerCase())
.add("position", column.position())
.add("clustering_order",
column.clusteringOrder().toString().toLowerCase())
.add("type", type.asCQL3Type().toString());
+
+ // Dynamic data masking functions shouldn't be attached to columns
during rolling upgrades
+ // to avoid sending mutations with columns that are unknown to the old
nodes.
+ ColumnMask mask = column.getMask();
+ if (ColumnMask.clusterSupportsMaskedColumns())
+ {
+ if (mask == null)
+ {
+ rowBuilder.delete("mask_keyspace")
+ .delete("mask_name")
+ .delete("mask_argument_types")
+ .delete("mask_argument_values")
+ .delete("mask_argument_nulls");
+ }
+ else
+ {
+ FunctionName maskFunctionName = mask.function.name();
+
+ // Some arguments of the masking function can be null, but the
CQL's list type that stores them doesn't
Review Comment:
Just realized that we have methods to make the conversion from byte buffer
column values to CQL literals (`AbstractType#toCQLString`,
`CQL3Type#toCQLLiteral`), but we don't have methods for the opposite
conversion.
If we want `mask_argument_values` to be able to represent nulls we would
need to add the reverse parsing, so the argument values are stored with quotes,
escaping, etc. That would allow us to distinguish between, for example,
`'null'` and `'''null'''`. That parsing is currently done in antlr and
`Constants.Literal`. Bringing that parsing to `AbstractType` would probably
require some not entirely trivial refactoring, given how the conversion
functions are spread across abstract types, CQL types, serializers and antlr.
Not sure if that would be worth compared to the current approach, which is
more focused on overcoming the limitations of lists than on how we represent
values. I think that if we had support for nulls on lists we wouldn't store
quoted CQL values but just nulls.
However, storing the values as strings seems a win for readability, so I'm
changing that part to store the argument values as strings, but keeping the
boolean list of nulls. wdyt?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
