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 >
