You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2014/08/05 22:16:11 UTC
[jira] [Commented] (CASSANDRA-7697) UDF use new schema migration
[ https://issues.apache.org/jira/browse/CASSANDRA-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14086689#comment-14086689 ]
Aleksey Yeschenko commented on CASSANDRA-7697:
----------------------------------------------
Honestly, I don't see how this makes sense for UDFs exclusively, as a separate ticket. It's going to happen as part of CASSANDRA-6038.
I suggest you store UDFs along with the current schema tables - create a new system.schema_whatever table. I'll convert it later to post-6717 schema.
> UDF use new schema migration
> ----------------------------
>
> Key: CASSANDRA-7697
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7697
> Project: Cassandra
> Issue Type: Bug
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Fix For: 3.0
>
>
> UDF is the "prototype candidate" for new, fine granular schema migration.
> On the basic level, everything stays the same, more or less, except:
> # We might use separate versioning for migration messages (in addition to the messaging version)
> # For DROP X changes, we only encode what's necessary (the keyspace name, the table name, the timestamp). Not to save bytes, but to avoid going through a full schema merge on the node.
> # Include the type of change with all other schema changes, for the same reason.
> # For schema pulls, use a merkle tree or something similar, to only pull/apply the relevant changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)