You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2010/08/26 20:26:55 UTC
[jira] Created: (CASSANDRA-1437) Improve default
handling/validation for config.Metadata objects
Improve default handling/validation for config.Metadata objects
---------------------------------------------------------------
Key: CASSANDRA-1437
URL: https://issues.apache.org/jira/browse/CASSANDRA-1437
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Post CASSANDRA-1436, we'll be back to single Avro objects to describe schemas for client and internal use: it would be a good opportunity to improve our handling of defaults and our validation of config.*Metadata objects.
Right now, we have multiple ways to convert a CfDef to a CFMetaData object (for example), due to the differences between the defaults that should be chosen for a _new_ column family (when we receive the CfDef from a client), versus an _existing_ column family after a new setting has been added (deserializing a CfDef from disk). Finding a unified way to handle these two (potentially different) default values would be excellent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1437) Improve default
handling/validation for config.Metadata objects
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1437:
--------------------------------------
Fix Version/s: 0.7.1
(was: 0.7.0)
> Improve default handling/validation for config.Metadata objects
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1437
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Priority: Minor
> Fix For: 0.7.1
>
>
> Post CASSANDRA-1436, we'll be back to single Avro objects to describe schemas for client and internal use: it would be a good opportunity to improve our handling of defaults and our validation of config.*Metadata objects.
> Right now, we have multiple ways to convert a CfDef to a CFMetaData object (for example), due to the differences between the defaults that should be chosen for a _new_ column family (when we receive the CfDef from a client), versus an _existing_ column family after a new setting has been added (deserializing a CfDef from disk). Finding a unified way to handle these two (potentially different) default values would be excellent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1437) Improve default
handling/validation for config.Metadata objects
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903120#action_12903120 ]
Stu Hood commented on CASSANDRA-1437:
-------------------------------------
Related to 1436 but not dependent: it might be possible to implement a clean solution to the "two possible defaults" problem by preserving the fact that we have different objects in the private and public APIs. Public APIs could remain unions of ["valid", "null"], with a null Avro default, and programmatic defaults, and private APIs could call all fields required, and use Avro defaults.
> Improve default handling/validation for config.Metadata objects
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1437
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Priority: Minor
> Fix For: 0.7.0
>
>
> Post CASSANDRA-1436, we'll be back to single Avro objects to describe schemas for client and internal use: it would be a good opportunity to improve our handling of defaults and our validation of config.*Metadata objects.
> Right now, we have multiple ways to convert a CfDef to a CFMetaData object (for example), due to the differences between the defaults that should be chosen for a _new_ column family (when we receive the CfDef from a client), versus an _existing_ column family after a new setting has been added (deserializing a CfDef from disk). Finding a unified way to handle these two (potentially different) default values would be excellent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1437) Improve default
handling/validation for config.Metadata objects
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated CASSANDRA-1437:
--------------------------------
Comment: was deleted
(was: Marking as related to 1436 but not dependent: it might be possible to implement a clean solution to the "two possible defaults" problem by preserving the fact that we have different objects in the private and public APIs. Public APIs could remain unions of ["valid", "null"], with programmatic defaults, and private APIs could call all fields required, and uses defaults.)
> Improve default handling/validation for config.Metadata objects
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1437
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Priority: Minor
> Fix For: 0.7.0
>
>
> Post CASSANDRA-1436, we'll be back to single Avro objects to describe schemas for client and internal use: it would be a good opportunity to improve our handling of defaults and our validation of config.*Metadata objects.
> Right now, we have multiple ways to convert a CfDef to a CFMetaData object (for example), due to the differences between the defaults that should be chosen for a _new_ column family (when we receive the CfDef from a client), versus an _existing_ column family after a new setting has been added (deserializing a CfDef from disk). Finding a unified way to handle these two (potentially different) default values would be excellent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1437) Improve default
handling/validation for config.Metadata objects
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903585#action_12903585 ]
Stu Hood commented on CASSANDRA-1437:
-------------------------------------
The gist is that client objects need to be 'sanitized' (aka, have defaults filled in programmatically for optional fields), but that internal objects should never have optional fields.
> Improve default handling/validation for config.Metadata objects
> ---------------------------------------------------------------
>
> Key: CASSANDRA-1437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1437
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Priority: Minor
> Fix For: 0.7.0
>
>
> Post CASSANDRA-1436, we'll be back to single Avro objects to describe schemas for client and internal use: it would be a good opportunity to improve our handling of defaults and our validation of config.*Metadata objects.
> Right now, we have multiple ways to convert a CfDef to a CFMetaData object (for example), due to the differences between the defaults that should be chosen for a _new_ column family (when we receive the CfDef from a client), versus an _existing_ column family after a new setting has been added (deserializing a CfDef from disk). Finding a unified way to handle these two (potentially different) default values would be excellent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.