[
https://issues.apache.org/jira/browse/THRIFT-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570506#comment-16570506
]
Anthony Alayo commented on THRIFT-4611:
---------------------------------------
[~calcifer] as to your comment on the suggestion, that makes a lot of sense.
As to the first part with the misunderstanding, the big issue is that the
current generation of js code actually doesn't use the enums imported.
In the running example where Event.thrift uses a enum inside Common.thrift,
{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}
Variable Common_ttypes, which contains the exports from Common_types.js, isn't
actually used anywhere inside Events_types.js. It's just sitting there imported
at the top of the file. I don't believe this was intentional?
Because of this, when you use a mechanism like below for decoding a serialized
thrift string:
{code:java}
function readBytes (buffer, Model, callback) {
var client = new Model();
try {
var transport = new TFramedTransport(buffer);
var protocol = new TCompactProtocol(transport);
client.read(protocol);
process.nextTick(function () {
callback(null, client);
});
} catch (ex) {
process.nextTick(function () {
callback(ex);
});
}
}
{code}
The information about which enum a number came from is lost. I can visually see
after digging through the code where it probably came from by comparing the IDL
to the generated code, but among the generated code, there is no way to
associate the enum instance to its definition.
> 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: Wish
> Components: JavaScript - Library, Node.js - Library
> Affects Versions: 0.11.0
> Reporter: Anthony Alayo
> Priority: Minor
>
> 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)
