Re: [VOTE] Release Apache Cassandra 0.8.4
+1 On Aug 10, 2011 8:09 PM, "Sylvain Lebresne" wrote: > We just fixed a fairly serious bug with counter (CASSANDRA-3006 -- it is > serious in that it "corrupt" counters). Cassandra 0.8.3 also shipped with a > potential small upgrade problem (CASSANDRA-3011). There is no reason to wait > to give those to users (especially the counter fix), so I propose the > following artifacts for release as 0.8.4. > > SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1156253 > Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-015/org/apache/cassandra/apache-cassandra/0.8.4/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-015/ > > The artifacts as well as a debian package are also available here: > http://people.apache.org/~slebresne/ > > Because 0.8.3 has been release only 2 days ago, there hasn't been many changes > since then, and the said change are mainly trivial, so I propose an expedited > vote of 24 hours (longer if needed). > > [1]: http://goo.gl/DGZP5 (CHANGES.txt) > [2]: http://goo.gl/c8ZfD (NEWS.txt)
Re: Possible Bug in 0.8.2 with DynamicComposite range scans?
I've tried using the longer values (converted as hex, so respectively 012D3FDFA400 and 012D4E52B800, 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--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--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 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" + 129384000L >> > > >> > > "jeans" + 129409920L >> > > >> > > >> > > Here are the byte values (with spaces added to make the encoding of >> > > the composite easier to read) The format is 4 byte comparator
[VOTE RESULT] was: [VOTE] Release Apache Cassandra 0.8.4
Including myself, I count 3 binding +1's, 1 other +1 and no 0s, the vote passes. I'll get the artifacts published right away. On Thu, Aug 11, 2011 at 9:33 AM, Eldad Yamin wrote: > +1 > On Aug 10, 2011 8:09 PM, "Sylvain Lebresne" wrote: >> We just fixed a fairly serious bug with counter (CASSANDRA-3006 -- it is >> serious in that it "corrupt" counters). Cassandra 0.8.3 also shipped with > a >> potential small upgrade problem (CASSANDRA-3011). There is no reason to > wait >> to give those to users (especially the counter fix), so I propose the >> following artifacts for release as 0.8.4. >> >> SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1156253 >> Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-015/org/apache/cassandra/apache-cassandra/0.8.4/ >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecassandra-015/ >> >> The artifacts as well as a debian package are also available here: >> http://people.apache.org/~slebresne/ >> >> Because 0.8.3 has been release only 2 days ago, there hasn't been many > changes >> since then, and the said change are mainly trivial, so I propose an > expedited >> vote of 24 hours (longer if needed). >> >> [1]: http://goo.gl/DGZP5 (CHANGES.txt) >> [2]: http://goo.gl/c8ZfD (NEWS.txt) >
Re: Possible Bug in 0.8.2 with DynamicComposite range scans?
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.
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
> 012D3FDFA400 and 012D4E52B800, 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
> >>
> >> UserComponentScan 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--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--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.
> >> >
