Hi Sylvain, I noticed a couple of things that differ in your usage from what I'm doing.
I've defined the column family with these aliases. I tried this in the CLI, but it won't create the column family with these values. DynamicComposite(a=>AsciiType,b=>BytesType,i=>IntegerType,x=>LexicalUUIDType,l=>LongType,t=>TimeUUIDType,s=>UTF8Type,u=>UUIDType,A=>AsciiType(reversed=true),B=>BytesType(reversed=true),I=>IntegerType(reversed=true),X=>LexicalUUIDType(reversed=true),L=>LongType(reversed=true),T=>TimeUUIDType(reversed=true),S=>UTF8Type(reversed=true),U=>UUIDType(reversed=true)) I had the same (correct) results as you using the aliases above when the longs in the value range from 0 to 9 in my tests initially. However when I inserted the longs that represent the dates, I started seeing this error. Can you try it again using the long values and the aliases in my test? These higher values seem to cause the issue. 1293840000000l 1294099200000l Thanks, Todd On Wed, 2011-08-10 at 12:26 +0200, Sylvain Lebresne wrote: > Well, this seem to be on the hector side. > > I've tried the same example using the CLI, and: > > [default@unknown] create keyspace test; > 642e6f90-c336-11e0-0000-242d50cf1fd5 > Waiting for schema agreement... > ... schemas agree across the cluster > [default@unknown] use test; > Authenticated to keyspace: test > [default@test] create column family foobar with > comparator=DynamicCompositeType and key_validation_class=AsciiType and > default_validation_class=AsciiType; > 40032380-c337-11e0-0000-242d50cf1fd5 > Waiting for schema agreement... > ... schemas agree across the cluster > [default@test] set foobar[k]['UTF8Type@jeans:BytesType(reversed=true)@1'] = a; > Value inserted. > [default@test] get foobar[k]; > => (column=UTF8Type@jeans:BytesType(reversed=true)@01, value=a, > timestamp=1312970389512000) > Returned 1 results. > [default@test] set foobar[k]['UTF8Type@jeans:BytesType(reversed=true)@2'] = a; > Value inserted. > [default@test] get foobar[k]; > => (column=UTF8Type@jeans:BytesType(reversed=true)@02, value=a, > timestamp=1312970410712000) > => (column=UTF8Type@jeans:BytesType(reversed=true)@01, value=a, > timestamp=1312970389512000) > Returned 2 results. > > Now, the last query is not exactly the one you do, since it does a full row > query but the CLI don't support setting the start and end of a slice. However, > I have tried hard-coding the exact query into the CLI (with > start='UTF8Type@jeans' > and end='UTF8Type@jeans:!'), and it still returns the columns in the columns > in the right order (with the biggest second component first). > > -- > Sylvain > > On Wed, Aug 10, 2011 at 9:26 AM, Todd Nine <t...@spidertracks.com> wrote: > > Hi guys, > > I've been dealing with a problem in my JPA plugin for a couple days > > now. I've been able to create a native test in 0.8.2 that reproduces > > the issue. Here is the test. > > > > > > https://gist.github.com/3ce70eab8102d2555626 > > > > > > Essentially, here is what is happening. > > > > A dynamic composite with the following ordering is created in a column > > > > UTF8Type+BytesType(reversed= > > true). > > > > 2 columns are then inserted, without composite encoding, these are the 2 > > values > > > > "jeans" + 1293840000000L > > > > "jeans" + 1294099200000L > > > > > > Here are the byte values (with spaces added to make the encoding of > > the composite easier to read) The format is 4 byte comparator, 4 byte > > length, n field bytes, 1 byte comparator, then repeats > > > > Inserted: > > > > 8073 0005 6a65616e73 00 8042 0008 0000012d4b889b80 00 > > 8073 0005 6a65616e73 00 8042 0008 0000012d3c158780 00 > > > > Query start > > > > 8073 0005 6a65616e73 00 > > > > Query end > > > > 8073 0005 6a65616e73 01 > > > > Returned from Hector Results > > > > 8073 0005 6a65616e73 00 8042 0008 0000012d3c158780 00 > > 8073 0005 6a65616e73 00 8042 0008 0000012d4b889b80 00 > > > > > > Given that the first value is sorted normally, and the second value is > > reversed, I would expect the higher long value to appear before the > > lower one (the longs are dates) when the first value in the composite > > is equal. Is this the expected behavior, or is this a bug? > > > > Thanks, > > Todd > >
