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.
>>
