cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-11118) Consider removing support for custom types
Date Thu, 04 Feb 2016 10:57:40 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132139#comment-15132139
] 

Sylvain Lebresne edited comment on CASSANDRA-11118 at 2/4/16 10:57 AM:
-----------------------------------------------------------------------

As I mentioned offline, I'm a priori not necessarily in favor of this, mainly because it means
breaking backward compatibility for people using them (which I agree, is likely few people,
but is almost certainly more than 0) with no clear/easy upgrade path and that because we should
take backward compatibility seriously the benefit of removing them should be high, but I don't
see that benefit as I think the effort/code necessary to support custom types is pretty low.

But I'll also respond more precisely to some of the reasons above.

bq. Custom types and even composite types need to be expressed using 'blob syntax'

I don't see how that's a big problem: people should think of custom type as a way to get blobs
with specific server side validation and sorting. To me it's like saying we should remove
blobs because you have to use 'blob syntax' for them.

bq. Custom-type implementations become more difficult to maintain (by their developers) as
we add more functionality (e.g. JSON or CQL literal generation)

I don't see how JSON or "CQL literal generation" (whatever that means) would impact implementors
of a custom type since again, as far as CQL is concerned a custom type value is mainly just
a blob.  I do agree that custom types user sometimes have to update their implementation on
upgrade since we do make changes to {{AbstractType}}, but 1) I don't think that has been a
big deal so far and 2) it may be a justification for user to avoid them if they can (and they
can most of the time), but not a huge incentive for us to remove them.

bq. Operational support for custom types (installing and upgrading C* releases) is more difficult

As you said, not new and also more a justification why you should probably avoid them rather
than why we should absolutely remove them.

bq. We still maintain two type hierarchies for the "same thing" (column types):
one starting at CQL3Type and one at AbstractType

Yes, but we absolutely can fix that without removing custom types. We've never guaranteed
you won't have to update your server side implementation on upgrade so we can do whatever
we want on that front. We _can_ refactor the shit out of {{AbstractType}} (merging it with
CQL3Type and even removing the {{AbstractType}} name) without breaking CQL compatibility per-se.
And I'm totally fine doing that at some point btw.

bq. There is "no need" to maintain AbstractType as a client protocol requirement starting
with 4.x as Thrift will be removed.

I'm missing how custom types are a Thrift thing only. If you had a use case for say {{DynamicCompositeType}}
in Thrift, it's still valid in CQL. Again though, we certainly don't need to maintain {{AbstractType}},
just leave a way to declare custom types, which is not the same thing.


I'll finish by saying that I'm not so much defending custom types, which I agree are somewhat
exotic, than defending not breaking backward compatibility for what seems to be little benefit
to me. And who knows, maybe "a handful" of applications do have a genuinely smart and useful
use of those types.



was (Author: slebresne):
As I mentioned offline, I'm a priori not necessarily in favor of this, mainly because it means
breaking backward compatibility for people using them (which I agree, is likely few people,
but is almost certainly more than 0) with no clear/easy upgrade path and that because we should
take backward compatibility seriously the benefit of removing them should be high, but I don't
see that benefit as I think the effort/code necessary to support custom types is pretty low.

But I'll also respond more precisely to some of the reasons above.

bq. Custom types and even composite types need to be expressed using 'blob syntax'

I don't see how that's a big problem: people should think of custom type as a way to get blobs
with specific server side validation and sorting. To me it's like saying we should remove
blobs because you have to use 'blob syntax' for them.

bq. Custom-type implementations become more difficult to maintain (by their developers) as
we add more functionality (e.g. JSON or CQL literal generation)

I don't see how JSON or "CQL literal generation" (whatever that means) would impact implementors
of a custom type since again, as far as CQL is concerned a custom type value is mainly just
a blob.  I do agree that custom types user sometimes have to update their implementation on
upgrade since we do make changes to {{AbstractType}}, but 1) I don't think that has been a
big deal so far and 2) it may be a justification for user to avoid them if they can (and they
can most of the time), but not a huge incentive for us to remove them.

bq. Operational support for custom types (installing and upgrading C* releases) is more difficult

As you said, not new and also more a justification why you should probably avoid them rather
than why we should absolutely remove them.

bq. We still maintain two type hierarchies for the "same thing" (column types):
one starting at CQL3Type and one at AbstractType

Yes, but we absolutely can fix that without removing custom types. We've never guaranteed
you won't have to update your server side implementation on upgrade so we can do whatever
we want on that front. We _can_ refactor the shit out of {{AbstractType}} (merging it with
CQL3Type and even removing the {{AbstractType}} name) without breaking CQL compatibility per-se.
And I'm totally fine doing that at some point btw.

bq. There is "no need" to maintain AbstractType as a client protocol
requirement starting with 4.x as Thrift will be removed.

I'm missing how custom types are a Thrift thing only. If you had a use case for say {{DynamicCompositeType}}
in Thrift, it's still valid in CQL. Again though, we certainly don't need to maintain {{AbstractType}},
just leave a way to declare custom types, which is not the same thing.


I'll finish by saying that I'm not so much defending custom types, which I agree are somewhat
exotic, than defending not breaking backward compatibility for what seems to be little benefit
to me. And who knows, maybe "a handful" of applications do have a genuinely smart and useful
use of those types.


> 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