[
https://issues.apache.org/jira/browse/CASSANDRA-19560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030538#comment-18030538
]
Bret McGuire commented on CASSANDRA-19560:
------------------------------------------
Tagging [~joaoreis] here; he and I were talking about this ticket some
yesterday and I know he has some thoughts.
I suppose I'm a bit skeptical about the idea of modeling this info via UDTs.
[~smiklosovic] has included a PR for the Python driver which would gather UDTs
defined in system_virtual_keyspace which could then be used for other virtual
tables. Thing is we'd want to add that to _all_ the drivers, not just Python.
To make this even worse it looks like gocql currently has zero support for
system_virtual_keyspace at all.
And that's just the drivers maintained by DataStax (some of which are in the
process of being donated to the ASF). Third-party drivers would need to update
as well, possibly more significantly.
I'm also wondering if a driver change might be premature. It appears that the
design of the "guardrails in CQL" feature is still evolving, which leaves me
worried that we might add support for this feature while the underlying
implementation has moved on from UDTs. I'm wondering if perhaps we should nail
this down a bit more before we pursue driver changes... [~smiklosovic] you're
probably best situated to speak to that.
I guess with these considerations in mind I do wonder whether a UDT truly
offers enough benefit over a straight tuple for use in this table.
> 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]
