[
https://issues.apache.org/jira/browse/CASSANDRA-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887893#action_12887893
]
Stu Hood commented on CASSANDRA-1186:
-------------------------------------
> DOB.buffer() could be private.
> No point in implementing OB.reset().
I'll fix these in the next round.
> Why OB.asByteArray instead of overwriting toByteArray?
Because toByteArray makes a guarantee to copy the data, but asByteArray can
avoid copies fairly regularly for one-time use buffers.
> I don't see the utility of 0007. I think it increases the coupling.
It does actually add a few lines, its true: but makeDefinitionsMutation only
mutates the Definitions table, and it was duplicating the serialization logic
in loadFromStorage. 0007 removes that duplication.
> Why store the keyspace in a single column? Writes were atomic before when
> they were in a single ColumnFamily.
I was worried about multiple Migrations running at once, and needing isolation:
perhaps only one Migration should run at once, so this isn't necessary?
> I think you should go further and get rid of all the members in CFMD and KSMD.
I'll give this a shot.
> I think things would be tidier if CfDef/ColumnFamily and KsDef/Keyspace were
> the same.
I agree, but I didn't see a good way to handle the private field: options seem
to be:
* validation that rejects CfDefs with an ID set (likely to bite everyone)
* ignoring the ID on a CfDef (likely to confuse people)
* having private and public objects
> futureproof [KS|CF]MetaData
> ---------------------------
>
> Key: CASSANDRA-1186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1186
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7
> Reporter: Jonathan Ellis
> Assignee: Stu Hood
> Priority: Critical
> Fix For: 0.7
>
> Attachments:
> 0001-Move-Yaml-related-classes-aside-to-reuse-names.patch,
> 0002-Extract-Avro-generation-and-begin-generating-an-inte.patch,
> 0003-Split-OutputBuffer-out-for-reuse.patch,
> 0004-Add-utility-functions-for-dealing-with-Avro-serializ.patch,
> 0005-Replace-serialization-code-in-KS-CF-CMetaData.patch,
> 0006-Port-Migrations-and-DefsTable-to-Avro.patch,
> 0007-Separate-Definitions-from-Migrations.patch
>
>
> KSMetaData/CFMetaData serialization is fragile. We need to be able to add
> fields easily without breaking when we read old-style serialized bytes.
> Avro and Thrift are designed to handle this. We should probably use one of
> those rather than re-inventing the wheel. If Avro is mature enough for this
> then let's use that, otherwise let's use Thrift.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
