[
https://issues.apache.org/jira/browse/CASSANDRA-19560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030583#comment-18030583
]
João Reis commented on CASSANDRA-19560:
---------------------------------------
When I first heard about this I didn't like it much because UDTs are quite a
bit more complex compared to other C* types (which is the reason why
historically they have been associated with some bugs both on the server and
driver sides). However, if they are exposed in a different table than regular
UDTs and they are not required for the core functionality of the driver (like
system.local and system.peers) then it should be ok. Have you guys thought
what's going to be the process behind changing the UDTs that are returned in
those virtual tables? Let's say a cluster is in the middle of an upgrade, some
nodes have 1 version of that UDT schema and other nodes have another version.
If the driver caches the old UDT schema and queries the virtual table on a node
with the new version will there be an issue?
{quote}Created PR for Python driver here. It is kind of a chicken-egg problem.
I think that changes in the drivers should go first because when we ship this
first then drivers will not know how to parse that.
{quote}
Implementing something on the driver first (or in parallel) is ideal so that
users have a way to actually use the feature that was developed on the server
but we always have to keep in mind that most users don't upgrade to the latest
version of the driver right away. 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. I don't have full context on
this but if the idea behind making these changes go first on the driver is only
to provide a way for users to use some *new* guardrails tables/columns then
that's ok.
I do share Bret's concern in the fact that we don't really want to merge
changes on the driver before we are absolutely sure that these changes are
final on the server side.
> 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]
