[ 
https://issues.apache.org/jira/browse/THRIFT-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569763#comment-16569763
 ] 

Can Celasun commented on THRIFT-4611:
-------------------------------------

If I understand correctly, you are trying to decode arbitrary thrift-encoded 
objects without using the generated client. If that's the case, the lack of 
type information in the wire format is a feature, not a bug. Clients are 
supposed to know which type a particular field is (based on the id of the 
field) and decode it accordingly. In your case, the generated client knows 
"type" is an enum and can therefore use the integer value for parsing and 
validation.

> NodeJS thrift enums not mappable back to their string values
> ------------------------------------------------------------
>
>                 Key: THRIFT-4611
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4611
>             Project: Thrift
>          Issue Type: Bug
>          Components: Node.js - Compiler
>    Affects Versions: 0.11.0
>            Reporter: Anthony Alayo
>            Priority: Major
>
> While attempting to build a javascript-based web tool to read encoded thrift 
> objects, I hit a wall. While I was able to decode from a base64 thrift string 
> to an object, all enum fields are only in their numeral representations with 
> no way to reverse them.
>  
> Here is one example, where there is a Common.thrift file containing enums, 
> and an Event.thrift using one of the enums from Common.thrift.
>  
> Here is the generated Event_types.js:
> {code:java}
> var Common_ttypes = require('./Common_types');
> var ttypes = module.exports = {};
> var Event = module.exports.Event = function(args) {
> this.id = null;
> this.type = null;
> ...
> }
> {code}
> Here is the generated Common_types.js
> {code:java}
> var ttypes = module.exports = {};
> ttypes.EventType = {
> 'OUTBOUND' : 0,
> 'INBOUND' : 1,
> }{code}
> While Common_types is being required in Event_types, there is no use of it 
> anywhere. The field type is solely being treated as a number:
> {code:java}
> if (this.type !== null && this.type !== undefined) {
> output.writeFieldBegin('type', Thrift.Type.I32, 3);
> output.writeI32(this.type);
> output.writeFieldEnd();
> }
> {code}
>  
> It seems to be a bug, since I assume from the import that we would expect to 
> use enums instead of numbers. Perhaps this is intended, but if that's the 
> case, could this be made into a feature? The ability to know and display the 
> enum string values instead of a number is a game changer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to