[
https://issues.apache.org/jira/browse/THRIFT-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570416#comment-16570416
]
Anthony Alayo commented on THRIFT-4611:
---------------------------------------
Thanks for all the replies everyone.
[~calcifer], I believe [~bforbis] updated his response to say there is indeed
no workaround right now,
"If however you are trying to build a generic tool that can stringify a thrift
object for display to humans, I don't think there is a way to automatically
convert the enum code into a string without knowing that you need to do it
first."
His second paragraph backs that up by saying a redesign of the generated thrift
code would be necessary. This is more inline with what I've discovered
(although I could be easily wrong) while digging through the code. To help
clarify this more, here is a piece of code from a thrift-serializer library
that uses the thrift lib on NPM:
[https://www.npmjs.com/package/thrift-serializer]
[https://github.com/guardian/thrift-serializer/blob/master/nodejs/src/index.js]
{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}
Taking the client object here and rendering it as a JSON on the browser is
almost there in terms of making a serialized thrift string decoded and human
readable. However as I was noting at the beginning of the ticket, there is no
way it seems to be able to return an enum string instead of numbers for enums.
As I don't know the actual generation code I can't gauge how difficult this
would be, but I would imagine it would look something like this (using the
pieces of code from earlier):
Here is the same 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 same generated Common_types.js:
{code:java}
var ttypes = module.exports = {};
ttypes.EventType = {
'OUTBOUND' : 0,
'INBOUND' : 1,
}{code}
And here is the modified setter for type inside Event_types.js:
{code:java}
if (this.type !== null && this.type !== undefined) {
output.writeFieldBegin('type', Common_ttypes.EventType, 3);
output.writeMap(this.type); // key and value here would be string and number
output.writeFieldEnd();
}
{code}
Where writeMap would be something more accurate to handle both values, so the
information of the enum string isn't lost. Would that be feasible?
I just wanted to make sure I was on the same page that right now reversing the
enum number to string isn't possible with the currently generated js.
> 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)
