Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 12 Aug 2014 10:35:11 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12733439.1407838128056.62416.1407839711834@arcas>
In-Reply-To: <JIRA.12733439.1407838128056@arcas>
References: <JIRA.12733439.1407838128056@arcas>
Subject: [jira] [Resolved] (CASSANDRA-7755) GZIPBase64 Validator
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CASSANDRA-7755?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne resolved CASSANDRA-7755.
-----------------------------------------

    Resolution: Won't Fix

I don't think there is any particular reason fo us to add this as a a defau=
lt validator: you can absolutely use your own AbstractType without any code=
 patching (just drop your jar in the class, you *can* then use it as valida=
tor in the CLI by using the fully qualified class name) and this gzip-then-=
base64-in-strings encoding feels rather specific to me (I can understand wa=
nting to compress values but using base64 encoding instead of just storing =
compressed values as blobs is imo certainly not standard).


> GZIPBase64 Validator
> --------------------
>
>                 Key: CASSANDRA-7755
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7755
>             Project: Cassandra
>          Issue Type: Wish
>            Reporter: Srikanth Seshadri
>            Priority: Minor
>
> I have implemented this extension.
> https://github.com/sriki77/cassandra
> Please let me know if you think it will be useful for others. If yes, I w=
ork on submitting a patch for the same
> ---------
> Extension: GZIP-Base64 Datatype
> For size advantages - we compress the text data in Text/UTF-8 columns in =
cassandra. The text is GZIPed and then Base64 encoded - result is stored in=
 Cassandra.
> When we peek into the data using Cassandra-Cli, the data we see is not in=
 clear text - this benefit is lost because of compression. Hence I added th=
is extension which indicates to Cassandra that the data in the text column =
is GZIP-Base64 encoded. The extension will decode the value and display the=
 result in clear text when queried.
> Usage
> Let=E2=80=99s assume that the employee column family has address column d=
ata in compressed format. Execute the following assumption in Cassandra-Cli=
.
> ASSUME employee VALIDATOR AS GZIPBASE64;
> With this assumption the output of the address column will be in clear te=
xt. The GZIPBASE64 type is implemented in such a way that it detects data f=
or compression, only then decodes it. If no compression is performed, the d=
ata is not altered.
> This implementation relieves the user of indicating, in the above example=
 that only address column is compressed and others are not
> --------.


--
This message was sent by Atlassian JIRA
(v6.2#6252)