[
https://issues.apache.org/jira/browse/CASSANDRA-19560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030628#comment-18030628
]
João Reis commented on CASSANDRA-19560:
---------------------------------------
{quote}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 ...
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.
{quote}
(y) fair points
{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
we can pretty much change what it returns from version to version, kind of.
{quote}
I was mostly referring to the fact that the driver caches the UDT schema and
uses that cached information when reading the results of a query so if the
driver has the old schema cached (retrieved from a node on the previous version
of C*) and then queries the column on a node that has the newer version of C*
there might be an issue. But errors during this time where a C* version upgrade
is in progress might be acceptable?
With "normal" UDTs I think the driver receives an event when the udt schema is
altered and the driver reacts to it by refreshing the UDT cache (correct me if
I'm wrong [~absurdfarce] )
> 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]
