[
https://issues.apache.org/jira/browse/CASSANDRA-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13563073#comment-13563073
]
Jonathan Ellis commented on CASSANDRA-3281:
-------------------------------------------
bq. I really think we should have client libraries break blobs up into native
C* fields, rather than creating a pseudo-supercolumn construct
Still agree with this; also relevant that CQL3 collections solve a large part
of this in a more-performant fashion. (E.g., you can append a new Map entry
without rewriting the whole collection.)
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
