You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Jordan (JIRA)" <ji...@apache.org> on 2010/07/08 09:08:50 UTC
[jira] Updated: (THRIFT-816) returning null for an object, sets it
to a dummy object with all zero/default values as opposed to returning
null.
[ https://issues.apache.org/jira/browse/THRIFT-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jordan updated THRIFT-816:
--------------------------
Description:
Please let me know if this is supposed to be standard behavior or just resolve if this is a feature not a bug. This may also be related to the problem of lists being deserialized incorrectly.
Basically if I a data type type:
ResponseObject {
1: ResponseDetail responseDetail
}
And I have a service call method that returns something of type ResponseObject
service TheService {
ResponseObject makeCall()
}
If the implementation of makeCall returns a ResponseObject with responseDetail set to null, then on the javascript client I will get a ResponseObject with a ResponseDetail that is NOT null. Instead it will be an object with not much character to it (all booleans will be false, all numbers will be zero etc.) I would expect nulls to come across the wire properly and show up as nulls on the client. Am I mistaken?
Someone please confirm that this is a bug and not an intended feature.
I will try to track down where this is coming from, but I might get stuck.
I would really like to get all these bugs ironed out, so if someone could dedicate about an hour of their time sometime within the next weak, to have a phone conversation about the code base, I can begin to help more effectively instead of just filing bug reports.
I honestly think that this javascript target of thrift is one of the most important components of the entire project. I commend the developers and would love to help out.
was:
Please let me know if this is supposed to be standard behavior or just resolve if this is a feature not a bug. This may also be related to the problem of lists being deserialized incorrectly.
Basically if I a data type type:
ResponseObject {
1: ResponseDetail responseDetail
}
And I have a service call method that returns something of type ResponseObject
service TheService {
ResponseObject makeCall()
}
And the implementation of makeCall returns a ResponseObject with responseDetail set to null, then on the javascript client I will get a ResponseObject with a ResponseDetail that is NOT null. Instead it will be an object with not much character to it (all booleans will be false, all numbers will be zero etc.)
Someone please confirm that this is a bug and not an intended feature.
I will try to track down where this is coming from, but I might get stuck.
I would really like to get all these bugs ironed out, so if someone could dedicate about an hour of their time sometime within the next weak, to have a phone conversation about the code base, I can begin to help more effectively instead of just filing bug reports.
I honestly think that this javascript target of thrift is one of the most important components of the entire project. I commend the developers and would love to help out.
> returning null for an object, sets it to a dummy object with all zero/default values as opposed to returning null.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-816
> URL: https://issues.apache.org/jira/browse/THRIFT-816
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (JavaScript)
> Affects Versions: 0.4
> Reporter: Jordan
>
> Please let me know if this is supposed to be standard behavior or just resolve if this is a feature not a bug. This may also be related to the problem of lists being deserialized incorrectly.
> Basically if I a data type type:
> ResponseObject {
> 1: ResponseDetail responseDetail
> }
> And I have a service call method that returns something of type ResponseObject
> service TheService {
> ResponseObject makeCall()
> }
> If the implementation of makeCall returns a ResponseObject with responseDetail set to null, then on the javascript client I will get a ResponseObject with a ResponseDetail that is NOT null. Instead it will be an object with not much character to it (all booleans will be false, all numbers will be zero etc.) I would expect nulls to come across the wire properly and show up as nulls on the client. Am I mistaken?
> Someone please confirm that this is a bug and not an intended feature.
> I will try to track down where this is coming from, but I might get stuck.
> I would really like to get all these bugs ironed out, so if someone could dedicate about an hour of their time sometime within the next weak, to have a phone conversation about the code base, I can begin to help more effectively instead of just filing bug reports.
> I honestly think that this javascript target of thrift is one of the most important components of the entire project. I commend the developers and would love to help out.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (THRIFT-816) returning null for an object, sets
it to a dummy object with all zero/default values as opposed to returning
null.
Posted by Roger Meier <ro...@bufferoverflow.ch>.
I fully agree!
JavaScript binding is a great thing and its potential is enormous!
It should absolutly be a part of Thrift.
As already written, I propose starting with a powerful testing framwork
for JavaScript, to have similar testing capabilities as with C++ or
other languages.
Currently I have a working test/cpp/srcTestServer.cpp and client using
the C++ HttpServer, provided by
https://issues.apache.org/jira/browse/THRIFT-247
I did some Test and reproduced that error mentioned in
https://issues.apache.org/jira/browse/THRIFT-816
on wire: [1,"testList",2,0,{"0":{"lst":["i32",3,3,2,1]}}]
I propose choosing a mature JavaScript unit test framework, e.g.
QUnit(what's state-of-the-art?) and implement unit tests on
http://svn.apache.org/repos/asf/incubator/thrift/trunk/lib/js/test/test.html
I'm ready to contribute!
Roger
Am 08.07.2010 09:08, schrieb Jordan (JIRA):
>
> [ https://issues.apache.org/jira/browse/THRIFT-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Jordan updated THRIFT-816:
> --------------------------
>
> Description:
> Please let me know if this is supposed to be standard behavior or just resolve if this is a feature not a bug. This may also be related to the problem of lists being deserialized incorrectly.
>
> Basically if I a data type type:
> ResponseObject {
> 1: ResponseDetail responseDetail
> }
>
> And I have a service call method that returns something of type ResponseObject
> service TheService {
> ResponseObject makeCall()
> }
>
> If the implementation of makeCall returns a ResponseObject with responseDetail set to null, then on the javascript client I will get a ResponseObject with a ResponseDetail that is NOT null. Instead it will be an object with not much character to it (all booleans will be false, all numbers will be zero etc.) I would expect nulls to come across the wire properly and show up as nulls on the client. Am I mistaken?
>
> Someone please confirm that this is a bug and not an intended feature.
> I will try to track down where this is coming from, but I might get stuck.
>
> I would really like to get all these bugs ironed out, so if someone could dedicate about an hour of their time sometime within the next weak, to have a phone conversation about the code base, I can begin to help more effectively instead of just filing bug reports.
> I honestly think that this javascript target of thrift is one of the most important components of the entire project. I commend the developers and would love to help out.
>
> was:
> Please let me know if this is supposed to be standard behavior or just resolve if this is a feature not a bug. This may also be related to the problem of lists being deserialized incorrectly.
>
> Basically if I a data type type:
> ResponseObject {
> 1: ResponseDetail responseDetail
> }
>
> And I have a service call method that returns something of type ResponseObject
> service TheService {
> ResponseObject makeCall()
> }
>
> And the implementation of makeCall returns a ResponseObject with responseDetail set to null, then on the javascript client I will get a ResponseObject with a ResponseDetail that is NOT null. Instead it will be an object with not much character to it (all booleans will be false, all numbers will be zero etc.)
>
> Someone please confirm that this is a bug and not an intended feature.
> I will try to track down where this is coming from, but I might get stuck.
>
> I would really like to get all these bugs ironed out, so if someone could dedicate about an hour of their time sometime within the next weak, to have a phone conversation about the code base, I can begin to help more effectively instead of just filing bug reports.
> I honestly think that this javascript target of thrift is one of the most important components of the entire project. I commend the developers and would love to help out.
>
>
>> returning null for an object, sets it to a dummy object with all zero/default values as opposed to returning null.
>> -------------------------------------------------------------------------------------------------------------------
>>
>> Key: THRIFT-816
>> URL: https://issues.apache.org/jira/browse/THRIFT-816
>> Project: Thrift
>> Issue Type: Bug
>> Components: Compiler (JavaScript)
>> Affects Versions: 0.4
>> Reporter: Jordan
>>
>> Please let me know if this is supposed to be standard behavior or just resolve if this is a feature not a bug. This may also be related to the problem of lists being deserialized incorrectly.
>> Basically if I a data type type:
>> ResponseObject {
>> 1: ResponseDetail responseDetail
>> }
>> And I have a service call method that returns something of type ResponseObject
>> service TheService {
>> ResponseObject makeCall()
>> }
>> If the implementation of makeCall returns a ResponseObject with responseDetail set to null, then on the javascript client I will get a ResponseObject with a ResponseDetail that is NOT null. Instead it will be an object with not much character to it (all booleans will be false, all numbers will be zero etc.) I would expect nulls to come across the wire properly and show up as nulls on the client. Am I mistaken?
>> Someone please confirm that this is a bug and not an intended feature.
>> I will try to track down where this is coming from, but I might get stuck.
>> I would really like to get all these bugs ironed out, so if someone could dedicate about an hour of their time sometime within the next weak, to have a phone conversation about the code base, I can begin to help more effectively instead of just filing bug reports.
>> I honestly think that this javascript target of thrift is one of the most important components of the entire project. I commend the developers and would love to help out.
>