Can now be followed at: https://issues.apache.org/jira/browse/CASSANDRA-7576
.
On Sat, Jul 19, 2014 at 1:03 PM, Karl Rieb <karl.r...@gmail.com> wrote:
> Will do!
>
> On Jul 19, 2014, at 11:22 AM, Robert Stupp <sn...@snazy.de> wrote:
>
> Can you submit a ticket in C* JIRA at issues.apache.org?
>
> --
> Sent from my iPhone
>
> Am 19.07.2014 um 16:45 schrieb Karl Rieb <karl.r...@gmail.com>:
>
> Ben! I think I have an idea of exactly where the bug is!
>
> I did some more searching and discovered the difference that causes some
> tables to produce the wrong type and others to be okay: *the tables with
> the wrong type reverse the ordering of the timestamp column*.
>
> The bug is in
> org.apache.cassandra.transport.DataType:fromType(AbstractType):
>
> public static Pair<DataType, Object> fromType(AbstractType type)
> {
> // For CQL3 clients, ReversedType is an implementation detail and
> they
> // shouldn't have to care about it.
> if (type instanceof ReversedType)
> type = ((ReversedType)type).baseType;
> // For compatibility sake, we still return DateType as the
> timestamp type in resultSet metadata (#5723)
> else if (type instanceof DateType)
> type = TimestampType.instance;
>
> DataType dt = dataTypeMap.get(type);
> if (dt == null)
> {
> if (type.isCollection())
> {
> if (type instanceof ListType)
> {
> return Pair.<DataType, Object>create(LIST,
> ((ListType)type).elements);
> }
> else if (type instanceof MapType)
> {
> MapType mt = (MapType)type;
> return Pair.<DataType, Object>create(MAP,
> Arrays.asList(mt.keys, mt.values));
> }
> else
> {
> assert type instanceof SetType;
> return Pair.<DataType, Object>create(SET,
> ((SetType)type).elements);
> }
> }
> return Pair.<DataType, Object>create(CUSTOM, type.toString());
> }
> else
> {
> return Pair.create(dt, null);
> }
> }
>
> The issue is the "else if", which does not check the base type of the
> reversed column:
>
> if (type instanceof ReversedType)
> type = ((ReversedType)type).baseType;
> // For compatibility sake, we still return DateType as the
> timestamp type in resultSet metadata (#5723)
> *else if* (type instanceof DateType)
> type = TimestampType.instance;
>
> The "else" should be removed to make it just:
>
> if (type instanceof ReversedType)
> type = ((ReversedType)type).baseType;
> // For compatibility sake, we still return DateType as the
> timestamp type in resultSet metadata (#5723)
> *if* (type instanceof DateType)
> type = TimestampType.instance;
>
> This way we do a check for DataType on the base type of reversed columns!
>
> I applied the fix to my 2.0.9 cassandra node and the errors go away!!!!!
>
> Could you guys please make this single-word fix?
>
> -Karl
>
>
>
> On Fri, Jul 18, 2014 at 1:30 PM, Ben Hood <0x6e6...@gmail.com> wrote:
>
>> On Fri, Jul 18, 2014 at 3:03 PM, Karl Rieb <karl.r...@gmail.com> wrote:
>> > Why is the protocol ID correct for some tables but not others?
>>
>> I have no idea.
>>
>> > Why does it work when I do a clean install on a new 2.0.x cluster?
>>
>> I still have no idea.
>>
>> > The bug seems to be on the Cassandra side and the clients seem to just
>> be providing patches to these issues.
>>
>> It was reported to the Cassandra list, but there was no answer,
>> potentially because the query was sent to the wrong list, but I don't
>> really know. Maybe it should have gone into Jira, but it's unclear as
>> to whether this is a client or a server issue.
>>
>> In any case, it didn't look like the server behavior was going to
>> change any time soon, so we just took the pragmatic approach in gocql
>> and worked around the issue.
>>
>> > I will post to the Datastax java driver mailing list and see if they
>> are willing to add a patch.
>>
>> That sounds like a good idea, seeing as the workaround has been tested
>> before.
>>
>> Sorry to be of little help to you.
>>
>
>
