Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 15 May 2012 22:11:08 +0000 (UTC)
From: "Aaron Morton (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <406520401.1552.1337119868761.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1303648213.977.1337057913491.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-4245) Provide a UT8Type (case
 insensitive) comparator
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-4245?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13276274#comment-13276274 ]=20

Aaron Morton commented on CASSANDRA-4245:
-----------------------------------------

Was thinking about the impact of case insensitive comparisons.

Say we have the values: aaron, Aaron, AARON, =C3=84aron, BOB and bob. Using=
 a Case Insensitive, Accent Sensitive collation the order should be (am usi=
ng bytes as a secondary ordering, and guessing =C3=84 occurs after the non =
accented A):

1. AARON, Aaron, aaron
2. =C3=84aron
3. Bob, bob

We need to decide if the collation above results in three or six columns in=
 Cassandra.=20

Some examples of where the comparison is used:
 * When writing the sorted memtable we are not concerned with equality, onl=
y relative ordering which is: AARON, Aaron,  aaron, =C3=84aron, Bob, bob=20
* When apply a mutation to a CF we are concerned with equality, relative or=
dering is not important. The six columns should be treated as six unique va=
lues, or as three columns.=20
* When resolving a query we are concerned with equality and relative orderi=
ng, but the equality is different to the examples above. We need to know th=
at the three non accented Aaron's are equal, and that Bobs occur later.=20

If three columns writing "AARON" then "aaron" then reading "aaron" may resu=
lt in "AARON" being returned. When reducing columns in a slice we need a de=
terministic way to select the column name to use in the response. And / or =
we the response digest needs to be calculated differently. =20
=20
If six columns comparators need to support a "unique ordering" that is used=
 in memtables and sstables, and a "query ordering" used when slicing. In th=
e example query ordering results in 3 unique values, unique ordering result=
s in 6. =20

I _think_ 3 columns is what we want. Thoughts ?=20

wrt the configuration, collation could be a CF level configuration used by =
comparators that support it. Per column collation would only be used by sec=
ondary indexing and seems a little overkill.=20
               =20
> Provide a UT8Type (case insensitive) comparator
> -----------------------------------------------
>
>                 Key: CASSANDRA-4245
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4245
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Ertio Lew
>            Priority: Minor
>
> It is a common use case to use a bunch of entity names as column names & =
then use the row as a search index, using search by range. For such use cas=
es & others, it is useful to have a UTF8 comparator that provides case inse=
nsitive ordering of columns.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira