I've tried using the longer values (converted as hex, so respectively 0000012D3FDFA400 and 0000012D4E52B800, since that is what the CLI can understand) and with the exact DynamicCompositeType declaration above (almost exact, I've fixed DynamicComposite -> DynamicCompositeType). I've tried with and without actually using the aliases (that is, I tried with the aliases declared but without using them in the values I sent). I always got the right. I really think this is on the hector side at this point.
>> When performing the range scan for my test the method >> "getColumnComparator" on line 106 of the SliceQueryFilter is invoked. >> It's using the BytesType comparator, so it is comparing the second >> component. Well, maybe the problem is when you declare the column family then. Are you set you correctly set the DynamicCompositeType when you create the column family (check with the CLI maybe, using describe keyspace). Because the getColumnComparator should return the DynamicCompositeType, not BytesType. The comparison of the different component is done internally in DynamicCompositeType. >> However, the "reversed" boolean flag is set to false, so it's not >> correctly utilizing the columeReverseComparator instance when >> performing range scans. This is right, because the slice query itself is not reversed. Again, the comparison is internal to DynamicCompositeType that will use the ReverseType comparator to compare the second component. -- Sylvain >> This seems to be a disconnect between when a column is specified as >> "reversed" in the component itself, and reversed is specified in the >> range query. For each component, wouldn't you need to do this? >> >> reversed = user reversed ^ composite reversed >> >> This is the table I came up with for range scanning. True is forward, >> false is reverse >> >> User Component Scan direction >> false false false >> false true true >> true false true >> true true false >> >> >> >> >> Thanks, >> >> >> -- >> todd >> CHIEF SOFTWARE ENGINEER >> >> todd nine| spidertracks ltd | 117a the square >> po box 5203 | palmerston north 4441 | new zealand >> P: +64 6 353 3395 >> E: t...@spidertracks.co.nz W: www.spidertracks.com >> >> >> >> 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 >> > > > >
