[ 
https://issues.apache.org/jira/browse/CASSANDRA-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne resolved CASSANDRA-7857.
-----------------------------------------
    Resolution: Fixed

Our beloved leader has spoken!

More seriously, I agree with Jonathan, we do need to ship asap. And I'm 
convinced that while {{frozen}} may not be that hypothetical keyword that 
everyone agrees is perfect, it's rather good. It isn't too much overloaded 
(like {{serialized}}, {{static}} or {{final}} might be) and doesn't have too 
much of a positive connotation that would lead people to choose it by default 
like {{packed}} might have (except maybe for the absolute fans of the Disney 
movie, but those deserve misery anyway imo). The only other uses that we're 
aware of is Ruby Object#freeze (which as Jonathan points out is pretty close 
semantically) and Python's {{frozenset}}, which is described in the python doc 
by: "The frozenset type is immutable and hashable -- its contents cannot be 
altered after is created; however, it can be used as a dictionary key or as an 
element of another set"; I would be hard-pressed to come with a better 
description for our issue.

So I've committed {{frozen<>}} and I'll start the vote on rc7 with that.

If we really find a keyword that is universally accepted as so much better in 
the coming days and have strong regrets, there is always the possibility to add 
this new keyword as an alias and make sure we use that new perfect keyword in 
all docs/conversations.


> Ability to froze UDT
> --------------------
>
>                 Key: CASSANDRA-7857
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7857
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.1.0
>
>         Attachments: 7857-v2.txt, 7857.txt
>
>
> Currently, UDT are serialized into a single value. For 3.0, we want to change 
> that somewhat and allow updating individual subfields: CASSANDRA-7423 (and 
> ultimately, we'll probably allow querying subpart of UDT to some extend). 
> Also for 3.0, we want to allow some nesting of collections (CASSANDRA-7826).
> However, migrating the currently serialized UDT would be challenging. Besides 
> that, even with nested collections, we probably won't be able to support 
> nesting within map keys and sets without serializing (at the very least, not 
> initially). Also, it can be useful in some specific case to have UDT or 
> collections for PK columns, even if those are serialized.
> So we need a better way to distinguish when a composite types (collections & 
> UDT) are serialized (which imply you can't update subpart of the value, you 
> have to rewrite it fully) and when they are not. The suggestion is then to 
> introduce a new keyword, {{frozen}}, to indicate that a type is serialized:
> {noformat}
> CREATE TYPE foo (a int, b int);
> CREATE TABLE bar (
>     k frozen<foo> PRIMARY KEY,
>     m map<frozen<set<int>>, text>
> )
> {noformat}
> A big advantage is that it makes the downside (you can't update the value 
> without rewriting it all) clear and upfront.
> Now, as of 2.1, we only support frozen UDT, and so we should make this clear 
> by 1) adding the frozen keyword and 2) don't allow use of UDT unless they are 
> "frozen" (since that's all we really support). This is what this ticket 
> proposes to do. And this should be done in 2.1.0 or this will be a breaking 
> change.
> We will have a follow-up ticket that will extend {{frozen}} to collection, 
> but this is less urgent since this will be strictly an improvement.
> I'll note that in term of syntax, {{serialized}} was suggested as an 
> alternative to {{frozen}}. I personally have a minor preference for 
> {{serialized}} but it was argued that it had a "sequential" connotation which 
> {{frozen}} don't have. Changing that is still up for discussion, but we need 
> to reach a decision quickly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to