[
https://issues.apache.org/jira/browse/CASSANDRA-19560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030611#comment-18030611
]
Stefan Miklosovic commented on CASSANDRA-19560:
-----------------------------------------------
I can confirm that this might be a premature feature to include, yes. But at
the same time, while we can "always go without UDT in virtual tables", that
does not mean we _have to_. Why should we just artificially constrain ourselves
to not using UDTs, while technically possible, just because our initial
evaluation of how that might be done is perceived as something complicated? I
would try to work around these complications and figure out the solutions to
them ... because then we will not be able to this, that and plethora of other
things ...
{quote}Have you guys thought about what's going to be the process behind
changing the UDTs that are returned in those virtual tables?{quote}
Virtual tables are not saving anything on disk, it is just representation of
some internal structure or data we want to expose to a user. If you mean about
"changing their schema", that is a good question but since this is just in
memory and not on disk whole class of problems is avoided and can pretty much
change what is returns how we want from version to version, kind of.
{quote}
So requiring users to upgrade to the latest driver to use a new feature of
Cassandra is fine but asking them to upgrade the driver for their apps to not
break is not fine.
{quote}
I am not completely sure the latter would be the case. An ordinary user does
not have any need whatsoever to parse system virtual tables. This is
operator-level stuff.
> Implement support of UDTs for virtual tables
> --------------------------------------------
>
> Key: CASSANDRA-19560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19560
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We can not use user types in virtual tables. While it might look strange at
> first to ask for the support of this, currently we can not do something like
> this:
> {code:java}
> cqlsh> select * from system_guardrails.thresholds ;
> name | value
> -------------------------------+----------------------
> collection_size | {warn: 0, fail: 0}
> column_value_size | {warn: -1, fail: -1}
> columns_per_table | {warn: -1, fail: -1}
> ...
> {code}
> {code:java}
> VIRTUAL TABLE system_guardrails.thresholds (
> name text PRIMARY KEY,
> value settings
> ) WITH comment = 'Guardrails configuration table for thresholds';
> {code}
> because "settings" is a UDT
> {code:java}
> cqlsh> DESCRIBE type system_guardrails.settings ;
> CREATE TYPE system_guardrails.settings (
> warn bigint,
> fail bigint
> );
> {code}
> While this is not absolutely necessary to implement and it might be worked
> around by a simple tuple, it feels sad that user experience suffers.
> Supporting custom types for vtables is indeed possible so we should just do
> that.
> There is additional work needed to do this, because virtual types are not
> supported in python-driver, I had to do this:
> [https://github.com/smiklosovic/python-driver/commit/14b236bb471bc4a7e251a9f6b694de7885b339de]
> python-driver reads system_schema.types in order to show the correct output
> in cqlsh, as it has not recognized virtual types, it was always displaying
> the results like
> {code:java}
> settings(warn=-1, fail -1)
> {code}
> because it could not evaluate it differently.
> With the patch for python-driver, it will fetch it from
> system_virtual_schema.types, where it will be like:
> {code:java}
> cqlsh> select * from system_virtual_schema.types ;
> keyspace_name | type_name | field_names | field_types
> -------------------+-----------+------------------+----------------------
> system_guardrails | settings | ['warn', 'fail'] | ['bigint', 'bigint']
> (1 rows)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
