[
https://issues.apache.org/jira/browse/CASSANDRA-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177310#comment-13177310
]
Edward Capriolo commented on CASSANDRA-3281:
--------------------------------------------
That is one part of it. If you think deeper DynamicCompositeType is still
restrictive in some cases. Here are some very far fetched use cases that
DynamicCompositeType can not support. (I am not suggesting these are useful but
just to bring the limits of DynamicCompositeType to light.
A situation where each composite has a variable number of parts.
{noformat}
set ['ecapriolo']['a:b:c']['x']
set ['ecapriolo']['a:b']['y']
set ['ecapriolo']['a']['x:d']
{noformat}
Each column value could be a completely different serialized Java object.
{noformat}
set ['ecapriolo']['house'][' new House()']
set ['ecapriolo']['car'][' new Car()']
set ['ecapriolo']['new Foo()'][' new Bar()']
{noformat}
Specifying every possible type that could appear in metadata would be
impossible.
{noformat}
comparator='DynamicCompositeType(h=>HouseType,c=>CarType,f=foo....)'
{noformat}
The main goals of AnyType were:
* allow null for any type
* allow '' or null for row keys and column names
* allow all types to sort (and sort null) like a RDBMS
Along the way I realized:
* define rules for how two different AnyType's would sort. (In the application
they were created for) Not using this. Not storing int and string in same
column.
* I could also store arbitrary comparables (In the application they were
created for) not using this just seemed too cool to not code up at the moment.
* People are always telling you to use JSON to store blobs (it would be groovy
if JSON sorted in a non byte order way.
So if the 'main goals' I mentioned were part of c* I would never have made
anytype.
> 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
