On Fri, Aug 12, 2011 at 1:53 AM, Todd Nine <t...@spidertracks.com> wrote:
> Hi Sylvain,
> Could you share the command you used to create the CF with the
> pre-defined aliases? I'm constantly receiving this error when I use the
> following command.
>
> Syntax error at position 63: missing EOF at '('
>
>
> create column family test2 with
> comparator=DynamicCompositeType(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))
> and key_validation_class=AsciiType and default_validation_class=AsciiType;
>
> I'll keep digging. I have a it's most likely a disconnect between the
> serialization of the type aliases on the client and the treatment of
> aliases in Cassandra.
I think you're missing quotes. Try
comparator='DynamicCompositeType(a=>AsciiType,b=>BytesType,...)'. That
worked for me.
--
Sylvain
>
>
> Thanks,
> Todd
>
>
> On Thu, 2011-08-11 at 10:57 +0200, Sylvain Lebresne wrote:
>
>> 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
>> >> > >
>> >
>> >
>
