Robert Stupp created CASSANDRA-11118:
----------------------------------------

             Summary: 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)

Reply via email to