cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11118) Consider removing support for custom types
Date Mon, 08 Feb 2016 12:35:39 GMT

    [ 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)

Mime
View raw message