[jira] [Issue Comment Edited] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-06-01 Thread donal zang (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042217#comment-13042217
 ] 

donal zang edited comment on CASSANDRA-2231 at 6/1/11 3:16 PM:
---

Hi,
forgive me if the question is naive.
I'm using the release 
0.7(http://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.7.6-2/) and  
when I apply the patch , it can't find the file TypeParser.java :
{quote}
$patch -p1  0001-Add-compositeType-and-DynamicCompositeType_0.7.patch
patching file 
src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java
patching file src/java/org/apache/cassandra/db/marshal/CompositeType.java
patching file src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
can't find file to patch at input line 694
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff --git a/src/java/org/apache/cassandra/db/marshal/TypeParser.java 
b/src/java/org/apache/cassandra/db/marshal/TypeParser.java
|index a3fabc5..0b21042 100644
|--- a/src/java/org/apache/cassandra/db/marshal/TypeParser.java
|+++ b/src/java/org/apache/cassandra/db/marshal/TypeParser.java
--
File to patch: 
{quote}
So, am I missing something?

  was (Author: donal):
Hi,
forgive me if the question is naive.
I'm using the release 
0.7(http://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.7.6-2/) and  
when I apply the patch , it can't find the file TypeParser.java :
$patch -p1  0001-Add-compositeType-and-DynamicCompositeType_0.7.patch
patching file 
src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java
patching file src/java/org/apache/cassandra/db/marshal/CompositeType.java
patching file src/java/org/apache/cassandra/db/marshal/DynamicCompositeType.java
can't find file to patch at input line 694
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff --git a/src/java/org/apache/cassandra/db/marshal/TypeParser.java 
b/src/java/org/apache/cassandra/db/marshal/TypeParser.java
|index a3fabc5..0b21042 100644
|--- a/src/java/org/apache/cassandra/db/marshal/TypeParser.java
|+++ b/src/java/org/apache/cassandra/db/marshal/TypeParser.java
--
File to patch: 

So, am I missing something?
  
 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: New Feature
  Components: Contrib
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.8.1

 Attachments: 
 0001-Add-compositeType-and-DynamicCompositeType-v2.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v3.patch, 
 0001-Add-compositeType-and-DynamicCompositeType-v4.patch, 
 0001-Add-compositeType-and-DynamicCompositeType_0.7.patch, 
 CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Issue Comment Edited] (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-04-04 Thread Sylvain Lebresne (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015721#comment-13015721
 ] 

Sylvain Lebresne edited comment on CASSANDRA-2231 at 4/5/11 2:04 AM:
-

The thing is this, if we agree that for actual values, then end-of-component 
(eoc) is always 0, I don't see what could be the use for the start or end of a 
query to have anything after a eoc != 0, since for any comparison of the start 
(resp. end) with an actual value, the comparaison will return as soon as we 
compare that eoc.

Taking your example of start = (100+1): (10+0), when compared to any value 
(x:0):(y:0), the comparison will either return when comparing x to 100, and if 
x==100, will stop when comparing the eoc (returning then that start  value, so 
that query would typically return all value whose first component is strictly 
greater than 100).

  was (Author: slebresne):
The thing is this, if we agree that for actual values, then 
end-of-component (eoc) is always 0, I don't see what could be the use for the 
start or end of a query to have anything after a eoc != 0, since for any 
comparison of the start (resp. end) with an actual value, the comparaison will 
return as soon as we compare that eoc.

Taking your example of start = (100+1):(10+0), when compared to any value 
(x:0):(y:0), the comparison will either return when comparing x to 100, and if 
x==100, will stop when comparing the eoc (returning then that start  value, so 
that query would typically return all value whose first component is strictly 
greater than 100).
  
 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: Improvement
  Components: Contrib
Affects Versions: 0.7.3
Reporter: Ed Anuff
Assignee: Sylvain Lebresne
Priority: Minor
 Fix For: 0.7.5

 Attachments: CompositeType-and-DynamicCompositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Issue Comment Edited: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-03-17 Thread Ed Anuff (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008321#comment-13008321
 ] 

Ed Anuff edited comment on CASSANDRA-2231 at 3/18/11 4:30 AM:
--

From the email conversation around this earlier today, I'm wondering if a bit 
in the trailing byte at the end of each component could be used for a sort 
order flag?

For context, we're looking at doing something in the JPA implementation via 
annotations that's functionally similar to how App Engine defines indexes in 
it's index.yaml - 
http://code.google.com/appengine/docs/java/configyaml/indexconfig.html



  was (Author: edanuff):
From the email conversation around this earlier today, I'm wondering if a 
bit in the trailing byte at the end of each component could be used for a sort 
order flag?
  
 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: Improvement
  Components: Contrib
Affects Versions: 0.7.3
Reporter: Ed Anuff
Priority: Minor
 Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Issue Comment Edited: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-03-17 Thread Ed Anuff (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008321#comment-13008321
 ] 

Ed Anuff edited comment on CASSANDRA-2231 at 3/18/11 5:27 AM:
--

-From the email conversation around this earlier today, I'm wondering if a bit 
in the trailing byte at the end of each component could be used for a sort 
order flag?-

I'd like to suggest we put a byte just before the length/value part that if 
it's non-zero, reverses the comparer results.  Both component parts must have 
the same sort order byte (i.e. both are 0 or both are 1) or a RuntimeException 
is thrown.

For context, we're looking at doing something in the JPA implementation via 
annotations that's functionally similar to how App Engine defines indexes in 
it's index.yaml - 
http://code.google.com/appengine/docs/java/configyaml/indexconfig.html



  was (Author: edanuff):
From the email conversation around this earlier today, I'm wondering if a 
bit in the trailing byte at the end of each component could be used for a sort 
order flag?

For context, we're looking at doing something in the JPA implementation via 
annotations that's functionally similar to how App Engine defines indexes in 
it's index.yaml - 
http://code.google.com/appengine/docs/java/configyaml/indexconfig.html


  
 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: Improvement
  Components: Contrib
Affects Versions: 0.7.3
Reporter: Ed Anuff
Priority: Minor
 Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Issue Comment Edited: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-03-17 Thread Ed Anuff (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008321#comment-13008321
 ] 

Ed Anuff edited comment on CASSANDRA-2231 at 3/18/11 5:28 AM:
--

-From the email conversation around this earlier today, I'm wondering if a bit 
in the trailing byte at the end of each component could be used for a sort 
order flag?-

I'd like to suggest we put a byte just before the length/value part of the 
component that if it's non-zero, reverses the comparer results for that 
component.  Both component parts must have the same sort order byte (i.e. both 
are 0 or both are 1) or a RuntimeException is thrown.

For context, we're looking at doing something in the JPA implementation via 
annotations that's functionally similar to how App Engine defines indexes in 
it's index.yaml - 
http://code.google.com/appengine/docs/java/configyaml/indexconfig.html



  was (Author: edanuff):
-From the email conversation around this earlier today, I'm wondering if a 
bit in the trailing byte at the end of each component could be used for a sort 
order flag?-

I'd like to suggest we put a byte just before the length/value part that if 
it's non-zero, reverses the comparer results.  Both component parts must have 
the same sort order byte (i.e. both are 0 or both are 1) or a RuntimeException 
is thrown.

For context, we're looking at doing something in the JPA implementation via 
annotations that's functionally similar to how App Engine defines indexes in 
it's index.yaml - 
http://code.google.com/appengine/docs/java/configyaml/indexconfig.html


  
 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: Improvement
  Components: Contrib
Affects Versions: 0.7.3
Reporter: Ed Anuff
Priority: Minor
 Attachments: 0001-Add-compositeType-and-DynamicCompositeType.patch, 
 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Issue Comment Edited: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal

2011-03-02 Thread Todd Nine (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001615#comment-13001615
 ] 

Todd Nine edited comment on CASSANDRA-2231 at 3/2/11 8:42 PM:
--

Enforcing all columns to be the same would break our indexing.  Each row key is 
a different index, and the columns within that index are composed of different 
composite types.  If this was enforced at the CF level, we would require a 
different CF for each index.  Is it possible to allow both static and dynamic 
types by creating 2 composite index types?  I.E StaticComposite using your 
patch and DynamicComposite using Eds?

  was (Author: tnine):
Enforcing all columns to be the same would break our indexing.  Each row 
key is a different index, and the columns within that index are composed of 
different composite types.  If this was enforced at the CF level, we would 
require a different CF for each index.  Is it possible to allow both static and 
dynamic types by creating 2 composite index types?
  
 Add CompositeType comparer to the comparers provided in 
 org.apache.cassandra.db.marshal
 ---

 Key: CASSANDRA-2231
 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231
 Project: Cassandra
  Issue Type: Improvement
  Components: Contrib
Affects Versions: 0.7.3
Reporter: Ed Anuff
Priority: Minor
 Attachments: 0001-Add-compositeType.patch, 
 edanuff-CassandraCompositeType-1e253c4.zip


 CompositeType is a custom comparer that makes it possible to create 
 comparable composite values out of the basic types that Cassandra currently 
 supports, such as Long, UUID, etc.  This is very useful in both the creation 
 of custom inverted indexes using columns in a skinny row, where each column 
 name is a composite value, and also when using Cassandra's built-in secondary 
 index support, where it can be used to encode the values in the columns that 
 Cassandra indexes.  One scenario for the usage of these is documented here: 
 http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html.  Source for 
 contribution is attached and has been previously maintained on github here: 
 https://github.com/edanuff/CassandraCompositeType

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira