thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer" <jensge...@hotmail.com>
Subject Re: updating to longer ints
Date Wed, 27 Mar 2013 20:15:32 GMT
Hi Henrique,

> Since the i16 side wouldn't be able to read the i32's
> that would came either as an input or output of your
> function. Therefore, to make it work we would have
> to be able to read larger numbers too, and cast them
> down.

Agree. The size of the internal data field is the limit that counts, as the 
data have to be stored somewhere. So the last one would become then 
something like:

        case ::apache::thrift::protocol::T_I64:
            int64_t  tmp4712;
            xfer += iprot->readI16(tmp4712);
            if ( (tmp4712 < std::numeric_limits<int32_t>::min()) ||
                  (tmp4712 > std::numeric_limits<int32_t>::max())) {
              throw TProtocolException( TProtocolException::SIZE_LIMIT);
            }
            this->thing = (int32_t)tmp4712;
            this->__isset.thing = true;
            break;

All of this should be achieveable by means of a specialized protocol 
wrapper, so we don't even have to bloat (and modify) the generated code. 
Looking for a good name .... do you have one?

Jens


-----Urspr├╝ngliche Nachricht----- 
From: Henrique Mendon├ža
Sent: Tuesday, March 26, 2013 11:03 PM
To: user@thrift.apache.org ; dev@thrift.apache.org
Subject: Re: updating to longer ints

Hi Jens,

That's an interesting proposition, sorry for the delayed answer, but if I'm
not wrong with your example it would generate exceptions independently of
the side you update first.

Since the i16 side wouldn't be able to read the i32's that would came
either as an input or output of your function. Therefore, to make it work
we would have to be able to read larger numbers too, and cast them down.
This could be a little tricky for an user to understand the results, and
increase the complexity of the compiler quite a bit.

However, it's theoretically possible and I don't think it would affect the
performance that much.

- Henrique


On 15 March 2013 19:57, Jens Geyer <jensgeyer@hotmail.com> wrote:

> I think TCompactProtocol uses var length ints, achieving
>> something similar to what you mentioned.
>>
>
> Yep, but good point anyway.
>
>
>  Not that this would help w/ the original issue.
>>
>
> Of course, because it is only "something similar" and suffers from the
> same limitations. What the OP suggests and/or what I was thinking of is
> something like this (this would be generated C++ code for one field) :
>
>      case 1:
>        switch( ftype) {
>        case ::apache::thrift::protocol::T_BYTE:
>            int8_t   tmp4710;
>            xfer += iprot->readByte(tmp4710);
>            this->thing = tmp4710;
>            this->__isset.thing = true;
>            break;
>        case ::apache::thrift::protocol::T_I16:
>            int16_t  tmp4711;
>            xfer += iprot->readI16(tmp4711);
>            this->thing = tmp4711;
>            this->__isset.thing = true;
>            break;
>
>        case ::apache::thrift::protocol::T_I32:
>            xfer += iprot->readI32(this->thing);
>            this->__isset.thing = true;
>            break;
>        case ::apache::thrift::protocol::T_I64:
>            throw TProtocolException( TProtocolException::SIZE_LIMIT);
>        else
>          xfer += iprot->skip(ftype);
>            break;
>        }
>        break;
>
> and similarly with the generated write() code. This way all protocols
> would profit form it (except for those where it makes no difference with
> regard to serialized data, such as JSON).
>
> The two biggest problem that I see are a) it breaks compatibility, so we
> have to increase the VERSION number, and b) it might affect overall
> serialization/deserialization performance.
>
> Jens
>
>
>
>
>
>
>
>
>
> 


Mime
View raw message