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