[
https://issues.apache.org/jira/browse/CASSANDRA-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828214#comment-15828214
]
Aleksey Yeschenko commented on CASSANDRA-9425:
----------------------------------------------
bq. Well, actually, your motivations on this are lost on me. I'm certainly not
pretending that optimization was the most important thing ever, but as
mentioned in the original ticket it did show up in some profiling and the
"optimization" was beyond tiny and entirely encapsulated within the class. As
an aside, also not a fan of manually writting hashcode() methods when the
simpler Objects.hashcode() can be and was used.
I do want to get rid of the auth object in my metadata code because
conceptually I don't want metadata to be aware of auth. But once you get rid of
the field, memoising the hash code in the {{DataResource}} object itself
becomes meaningless, so you need to 'fix' {{DataResource.hashCode()}} properly,
too (in that JIRA, you claimed that the allocation of the array for varargs was
an issue; in reality it shouldn't be - once that code gets hot enough, it
should be stack allocated, but I have no flight recorder runs to prove it). So
should some of the allocated {{DataResource}} objects. TL;DR: I don't like this
part of the CASSANDRA-10410 ticket, but I don't care enough about this to fight
it, so I can revert my change.
> Make node-local schema fully immutable
> --------------------------------------
>
> Key: CASSANDRA-9425
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9425
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Fix For: 4.0
>
>
> The way we handle schema changes currently is inherently racy.
> All of our {{SchemaAlteringStatement}} s perform validation on a schema state
> that's won't necessarily be there when the statement gets executed and
> mutates schema.
> We should make all the *Metadata classes ({{KeyspaceMetadata,
> TableMetadata}}, {{ColumnMetadata}}, immutable, and local schema persistently
> snapshottable, with a single top-level {{AtomicReference}} to the current
> snapshot. Have DDL statements perform validation and transformation on the
> same state.
> In pseudo-code, think
> {code}
> public interface DDLStatement
> {
> /**
> * Validates that the DDL statement can be applied to the provided schema
> snapshot.
> *
> * @param schema snapshot of schema before executing CREATE KEYSPACE
> */
> void validate(SchemaSnapshot schema);
>
> /**
> * Applies the DDL statement to the provided schema snapshot.
> * Implies that validate() has already been called on the provided
> snapshot.
> *
> * @param schema snapshot of schema before executing the statement
> * @return snapshot of schema as it would be after executing the statement
> */
> SchemaSnapshot transform(SchemaSnapshot schema);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
