cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3281) Add an AbstractType anytype which stores meta data on a per column basis
Date Thu, 29 Dec 2011 18:39:32 GMT


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.
set ['ecapriolo']['a:b:c']['x']
set ['ecapriolo']['a:b']['y']
set ['ecapriolo']['a']['x:d']

Each column value could be a completely different serialized Java object. 
set ['ecapriolo']['house'][' new House()']
set ['ecapriolo']['car'][' new Car()']
set ['ecapriolo']['new Foo()'][' new Bar()']

Specifying every possible type that could appear in metadata would be impossible.

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:
>             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.
> I described my use case any my design decisions here.
. 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:!default.jspa
For more information on JIRA, see:


View raw message