Actually, I found the underlying issue...
CQL appends the *name* of the "value" column into the compound key.
Using the previous schema:
insert into data (uid, t, foo, bar) values ('PI7JC8KRF6',
'1349110576', 'foovalue', 'barvalue')
list data;
RowKey: PI7JC8KRF6
=> (column=1970-01-16 09:45:10-0500:foovalue:bar, value=barvalue,
timestamp=1349380029082000)
Notice "bar" is on the end of the column name.
If you don't have that element represented from the Java API (in this
case, w/ Astyanax), you end up with misaligned interpretation of the
compound key. I'll add an extra element to the composite type in
Astyanax, which should fix things. I'll also add this to my blog so
other people don't get tripped up.
Any insight into why CQL puts that in column name?
Where does it store the metadata related to compound key
interpretation? Wouldn't that be a better place for that since it
shouldn't change within a table?
-brian
On Thu, Oct 4, 2012 at 3:39 PM, Brian O'Neill <b...@alumni.brown.edu> wrote:
> Perfect. Tnx.
>
> On Thu, Oct 4, 2012 at 3:37 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
>> Oh, I see. I misunderstood at first. Yes, the thrift side in 1.1
>> doesn't validate cql3 composites. This should be fixed in 1.2 beta1;
>> see
>> https://issues.apache.org/jira/browse/CASSANDRA-4377?focusedCommentId=13436817&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13436817
>>
>> On Thu, Oct 4, 2012 at 2:31 PM, Brian O'Neill <b...@alumni.brown.edu> wrote:
>>> I was able to reproduce with CLI. I'll send over the example as soon
>>> as I can obfuscate it.
>>>
>>> -brian
>>>
>>> On Thu, Oct 4, 2012 at 3:19 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
>>>> Nothing jumps out at me, varchar should be pretty straightforward.
>>>> Probably going to need a test case. (Even better if you can repro w/
>>>> cli instead of needing Astyanax.)
>>>>
>>>> On Thu, Oct 4, 2012 at 2:15 PM, Brian O'Neill <b...@alumni.brown.edu>
>>>> wrote:
>>>>> Obfuscated slightly....
>>>>>
>>>>> The table is something simliar to:
>>>>>
>>>>> CREATE TABLE data (
>>>>> uid varchar,
>>>>> t timestamp,
>>>>> foo varchar,
>>>>> bar varchar,
>>>>> PRIMARY KEY (uid, t, foo, bar)
>>>>> );
>>>>>
>>>>> Then I can insert just fine via Astyanax and I can see the row via
>>>>> cli, but the select statement fails in cqlsh.
>>>>>
>>>>> The table is fine, when I only interact with it through CQL. I can
>>>>> insert and select fine, until I insert a row from Asytanax.
>>>>>
>>>>> If needed, I can probably create a small test for this that I can share.
>>>>>
>>>>> -brian
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 4, 2012 at 3:08 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
>>>>>> What kind of data did you insert, and what was expected? Expected
>>>>>> behavior would be to reject nonconforming data at insert time.
>>>>>>
>>>>>> On Thu, Oct 4, 2012 at 2:04 PM, Brian O'Neill <b...@alumni.brown.edu>
>>>>>> wrote:
>>>>>>> This is probably already on your radar, but we could use a better
>>>>>>> error message from cqlsh when the column key doesn't conform to the
>>>>>>> expected schema...
>>>>>>>
>>>>>>> I accidentally inserted data using Astyanax that didn't conform to the
>>>>>>> schema. After that, selects from that table via cqlsh return no
>>>>>>> useful information.
>>>>>>> (CLI shows the data just fine)
>>>>>>>
>>>>>>>
>>>>>>> bone@boneill-macbook-wired:~/tools/cassandra-> bin/cassandra-cli
>>>>>>> Connected to: "Test Cluster" on 127.0.0.1/9160
>>>>>>> Welcome to Cassandra CLI version 1.1.5
>>>>>>>
>>>>>>> Type 'help;' or '?' for help.
>>>>>>> Type 'quit;' or 'exit;' to quit.
>>>>>>>
>>>>>>> [default@unknown] use cirrus;
>>>>>>> Authenticated to keyspace: cirrus
>>>>>>> [default@cirrus] list data;
>>>>>>> Using default limit of 100
>>>>>>> Using default column limit of 100
>>>>>>> -------------------
>>>>>>> RowKey: PI7JC8
>>>>>>> => (column=*****, value=2014-07-31, timestamp=1349376866686000)
>>>>>>> -------------------
>>>>>>> RowKey: PI1234
>>>>>>> => (column=*****, value=Y, timestamp=1349372660453000)
>>>>>>>
>>>>>>> 2 Rows Returned.
>>>>>>> Elapsed time: 212 msec(s).
>>>>>>> [default@cirrus] quit;
>>>>>>> bone@boneill-macbook-wired:~/tools/cassandra-> bin/cqlsh -3
>>>>>>> Connected to Test Cluster at localhost:9160.
>>>>>>> [cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol
>>>>>>> 19.32.0]
>>>>>>> Use HELP for help.
>>>>>>> cqlsh> use cirrus;
>>>>>>> cqlsh:cirrus> select * from data;
>>>>>>> TSocket read 0 bytes
>>>>>>> cqlsh:cirrus>
>>>>>>>
>>>>>>> --
>>>>>>> Brian ONeill
>>>>>>> Lead Architect, Health Market Science (http://healthmarketscience.com)
>>>>>>> mobile:215.588.6024
>>>>>>> blog: http://brianoneill.blogspot.com/
>>>>>>> twitter: @boneill42
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jonathan Ellis
>>>>>> Project Chair, Apache Cassandra
>>>>>> co-founder of DataStax, the source for professional Cassandra support
>>>>>> http://www.datastax.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian ONeill
>>>>> Lead Architect, Health Market Science (http://healthmarketscience.com)
>>>>>
>>>>> mobile:215.588.6024
>>>>> blog: http://brianoneill.blogspot.com/
>>>>> twitter: @boneill42
>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Ellis
>>>> Project Chair, Apache Cassandra
>>>> co-founder of DataStax, the source for professional Cassandra support
>>>> http://www.datastax.com
>>>
>>>
>>>
>>> --
>>> Brian ONeill
>>> Lead Architect, Health Market Science (http://healthmarketscience.com)
>>>
>>> mobile:215.588.6024
>>> blog: http://brianoneill.blogspot.com/
>>> twitter: @boneill42
>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra support
>> http://www.datastax.com
>
>
>
> --
> Brian ONeill
> Lead Architect, Health Market Science (http://healthmarketscience.com)
>
> mobile:215.588.6024
> blog: http://brianoneill.blogspot.com/
> twitter: @boneill42
--
Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog: http://brianoneill.blogspot.com/
twitter: @boneill42
