[
https://issues.apache.org/jira/browse/CASSANDRA-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136889#comment-15136889
]
Aleksey Yeschenko commented on CASSANDRA-11118:
-----------------------------------------------
Don't have much to add to Sylvain's arguments, just throwing in my -1 to the
idea of removing support for them.
There is one thing that we care about when it comes to custom types - and that
is the ability to mandate them being byte order compatible in the future. But
we already decided to do so (see CASSANDRA-9901 and CASSANDRA-6936 discussions).
Closing the issue as Not A Problem.
> Consider removing support for custom types
> ------------------------------------------
>
> Key: CASSANDRA-11118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11118
> Project: Cassandra
> Issue Type: Wish
> Reporter: Robert Stupp
> Priority: Minor
>
> Custom types (and maybe all types that extend AbstractType but have no CQL3
> counterpart) become difficult to be properly supported.
> There are a couple of reasons:
> * Custom types and even composite types need to be expressed using 'blob
> syntax' as in CASSANDRA-11064 to provide full end-to-end support (C* nodes
> and all drivers).
> * Custom-type implementations become more difficult to maintain (by their
> developers) as we add more functionality (e.g. JSON or CQL literal
> generation) and contracts (like the different comparison modes and
> implementations) to AbstractType
> * Operational support for custom types (installing and upgrading C* releases)
> is more difficult (provide the correct custom-type implementations for the
> specific C* release; not a new reason, of course)
> * We still maintain two type hierarchies for the "same thing" (column types):
> one starting at CQL3Type and one at AbstractType (plus serializers), which
> are closely related and coupled.
> * There is "no need" to maintain AbstractType as a client protocol
> requirement starting with 4.x as Thrift will be removed. In reality, the
> support of drivers for composite types or even custom types is fairly
> rudimentary, if existent.
> * I'm also a bit concerned that there might be hidden issues related to this
> _old and rarely used and even least thought-of stuff_. I mean, we (at least
> I) don't always think about these old types. Like CASSANDRA-11064 that has
> the potential to bring down a cluster.
> I would not propose to remove custom types in 4.x but officially deprecate
> the functionality in the near future and communicate an "official" date
> (version number) when it will be removed.
> In the mean time there might be a configuration option like
> {{enable_custom_types}} or {{allow_non_cql3_types}} which defaults to
> {{false}} and either issues warnings (in the log and via native protocol)
> when those types are used in DDL statements or completely prevents that
> (returning an error, prevent startup, whatever). We can also convert all
> non-CQL3 types to BLOB in the schema tables as the "implementation to remove
> custom types".
> TBH, I have absolutely no idea how many people really use composite types or
> even custom types. But I assume that "only a handful" of applications really
> use non-CQL3 types with C* 4.x (so without Thrift).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
