[
https://issues.apache.org/jira/browse/CASSANDRA-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241431#comment-13241431
]
Jonathan Ellis commented on CASSANDRA-3281:
-------------------------------------------
I really think we should have client libraries break blobs up into native C*
fields, rather than creating a pseudo-supercolumn construct (with even more
disadvantages). Having admitted our mistake with supercolumns (see
CASSANDRA-3237) I'm not thrilled with the idea of adding something similar back.
> Add an AbstractType anytype which stores meta data on a per column basis
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-3281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3281
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Edward Capriolo
> Priority: Minor
>
> A pet project of mine is an AbstractType for Cassandra that stores metadata
> of the type in the column. https://github.com/edwardcapriolo/Cassandra-AnyType
> I described my use case any my design decisions here.
> https://github.com/edwardcapriolo/Cassandra-AnyType/blob/master/README . The
> biggest cases were needing to support null and '' as keys, column names, and
> column values, however I also think the technique used to serialize Java
> Objects as JSON but compare as a Java object is novel.
> Side node: (The AbstractType interface has changed multiple times between
> 0.6.X, 0.7.X, and 1.0.0-beta. I hope it stabilizes! )
> If people would like AnyType (or parts of it ) incorporated into Cassandra
> that would be great. I am willing to tweak change it based on other peoples
> ideas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
