[
https://issues.apache.org/jira/browse/CASSANDRA-20827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18014055#comment-18014055
]
Stefan Miklosovic edited comment on CASSANDRA-20827 at 8/15/25 7:42 AM:
------------------------------------------------------------------------
I am not completely sure I understand this. Some background first, there is
already JSON you can use like this:
{code}
cassandra@cqlsh> CREATE TYPE ks.mytype (id int, val map<int, text>);
cassandra@cqlsh> CREATE TABLE ks.tb3 (id int, values frozen<mytype>, primary
key (id));
cassandra@cqlsh> INSERT INTO ks.tb3 (id, values ) VALUES ( 1, {id: 5, val: {1:
'hello', 2: 'world'}});
cassandra@cqlsh> select * from ks.tb3;
id | values
----+----------------------------------------
1 | {id: 5, val: {1: 'hello', 2: 'world'}}
(1 rows)
cassandra@cqlsh> select json * from ks.tb3;
[json]
---------------------------------------------------------------------
{"id": 1, "values": {"id": 5, "val": {"1": "hello", "2": "world"}}}
(1 rows)
{code}
But I do not think this is suitable for this case, because our value column can
be of whatever structure.
Next, what we have in system_views.settings is _string representation of the
value_. So, I think that what you see is the result of HashMap.toString,
basically. Hence, the method you want to introduce, collection2json, is not
_converting collections to json_, because it is not _collection_, it is String,
it was just produced by HashMap.toString.
If you wanted to covert a value of some _collection type_ to json, you have
"select json ..." for that.
It would be more suitable if we introduced CQL _type_ which would be JSON. This
is not done yet. There was some discussions about that. BTW we do have a
constraint called JSON:
{code}
cassandra@cqlsh> CREATE TABLE ks.tb4 (id int, values text CHECK JSON, primary
key (id));
cassandra@cqlsh> INSERT INTO ks.tb4 (id , values ) VALUES ( 1, '{"this": {"is":
"a json"}}');
cassandra@cqlsh> INSERT INTO ks.tb4 (id , values ) VALUES ( 1, 'this is not');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Value for
column 'values' violated JSON constraint as it is not a valid JSON."
cassandra@cqlsh> select * FROM ks.tb4;
id | values
----+----------------------------
1 | {"this": {"is": "a json"}}
(1 rows)
{code}
So I think that while {{value}} column would be still technically _text_, we
might in theory put a JSON constraint on it. It means that every value in there
would look like JSON and it would be the responsibility of whoever is
populating that table that whatever text inserted would be a valid JSON.
I consider this to be unnecessary because we are the ones who populate that
table, so we do know what we want to put in there, there does not need to be a
constraint. This is simply just a view nobody is going to _insert_ into
anything to check its values on insert.
Lastly, while the patch indeed displays collections as valid JSON strings, the
small discrepancy I see is that _not every value is a json_. Basically we have
a column of value 'text' where scalars (numbers, strings) are displayed as
that, but collections as jsons. It is a good question to ask if we should not
do something like this instead:
{code}
auto_optimise_full_repair_streams | "false"
{code}
because {{"false"}} _is_ valid JSON, but {{false}} (currently present) is not.
was (Author: smiklosovic):
I am not completely sure I understand this. Some background first, there is
already JSON you can use like this:
{code}
cassandra@cqlsh> CREATE TYPE ks.mytype (id int, val map<int, text>);
cassandra@cqlsh> CREATE TABLE ks.tb3 (id int, values frozen<mytype>, primary
key (id));
cassandra@cqlsh> INSERT INTO ks.tb3 (id, values ) VALUES ( 1, {id: 5, val: {1:
'hello', 2: 'world'}});
cassandra@cqlsh> select * from ks.tb3;
id | values
----+----------------------------------------
1 | {id: 5, val: {1: 'hello', 2: 'world'}}
(1 rows)
cassandra@cqlsh> select json * from ks.tb3;
[json]
---------------------------------------------------------------------
{"id": 1, "values": {"id": 5, "val": {"1": "hello", "2": "world"}}}
(1 rows)
{code}
But I do not think this is suitable for this case, because our value column can
be of whatever structure.
Next, what we have in system_views.settings is _string representation of the
value_. So, I think that what you see is the result of HashMap.toString,
basically. Hence, the method you want to introduce, collection2json, is not
_converting collections to json_, because it is not _collection_, it is String,
it was just produced by HashMap.toString.
If you wanted to covert a value of some _collection type_ to json, you have
"select json ..." for that.
It would be more suitable if we introduced CQL _type_ which would be JSON. This
is not done yet. There was some discussions about that. BTW we do have a
constraint called JSON:
{code}
cassandra@cqlsh> CREATE TABLE ks.tb4 (id int, values text CHECK JSON, primary
key (id));
cassandra@cqlsh> INSERT INTO ks.tb4 (id , values ) VALUES ( 1, '{"this": {"is":
"a json"}}');
cassandra@cqlsh> INSERT INTO ks.tb4 (id , values ) VALUES ( 1, 'this is not');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Value for
column 'values' violated JSON constraint as it is not a valid JSON."
cassandra@cqlsh> select * FROM ks.tb4;
id | values
----+----------------------------
1 | {"this": {"is": "a json"}}
(1 rows)
{code}
So I think that while {{value}} column would be still technically _text_, we
might in theory put a JSON constraint on it. It means that every value in there
would look like JSON and it would be the responsibility of whoever is
populating that table that whatever text inserted would be a valid JSON.
I consider this to be unnecessary because we are the ones who populate that
table, so we do know what we want to put in there, there does not need to be a
constraint. This is simply just a view nobody is going to _insert_ into
anything to check its values on insert.
Lastly, while the patch indeed displays collections as valid JSON strings, the
small discrepancy I see is that _not every value is a json_. Basically we have
a column of value 'text' where scalars (numbers, strings) are displayed as
that, but collections as jsons. It is questionable if we should do something
like this:
{code}
auto_optimise_full_repair_streams | "false"
{code}
because {{"false"}} _is_ valid JSON, but {{false}} is not.
> Represent complex settings as JSON on system_views.settings table
> -----------------------------------------------------------------
>
> Key: CASSANDRA-20827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20827
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Paulo Motta
> Assignee: Marko Tsymbaliuk
> Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Complex configuration (maps/sets/lists) are represented as
> Collections.toString() on {{system.settings}} virtual table:
> {code:java}
> cqlsh> select * from system_views.settings where name='seed_provider' ;
> name | value
> ------+-------
> (0 rows)
> cqlsh> select * from system_views.settings where
> name='seed_provider.parameters' ;
> name | value
> --------------------------+------------------------
> seed_provider.parameters | {seeds=127.0.0.1:7000}
> {code}
> While this is fine for human consumption, it's not ideal for programmatic
> access, since it requires custom parsing.
> This ticket is to add ability of representing complex types as JSON on
> {{system.settings}} and potentially making it default in trunk, so the above
> would return:
> {code:java}
> cqlsh> select * from system_views.settings where name='seed_provider' ;
> name | value
> ------+-------
> (0 rows)
> cqlsh> select * from system_views.settings where
> name='seed_provider.parameters' ;
> name | value
> --------------------------+------------------------
> seed_provider.parameters | {"seeds": "127.0.0.1:7000"}{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
