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)