Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When parsing, there is no way to get int value of an enum #7

Open
kennberg opened this issue May 7, 2012 · 5 comments
Open

When parsing, there is no way to get int value of an enum #7

kennberg opened this issue May 7, 2012 · 5 comments

Comments

@kennberg
Copy link
Contributor

kennberg commented May 7, 2012

Right now when I parse a message in node, the enum value is set to string. However, string is not an efficient representation of enum. It takes longer to compare, it takes more space in the database, etc.

Possible solutions:

  1. Provide a mapping from string to int.
  2. Set option to always return int for enums.
  3. Generate a simple module that contains constants for all the enums in the protobuf.

Solutions #2 + #3 are likely to generate the nicest and most efficient server-side code.

@chrisdew
Copy link
Owner

chrisdew commented May 8, 2012

I've come across this myself. I like #2, but with the following options:

a) enums as ints
b) enums as strings
c) enums as objects of the form { int:13, string:"EACCES" }

@chrisdew
Copy link
Owner

chrisdew commented May 8, 2012

I've done #3 for one enum:

var reasonToNum = createReasonToNum();

/*
 * create a reason text -> num lookup table
 */
function createReasonToNum() {
  var map = {};
  for (var i = 1; i < 255; i++) {
    try {
      var ad = ApplicationData.parse(ApplicationData.serialize({ reason: i }));
      map[ad.reason] = i;
    } catch (e) {
      // FIXME: be more discerning and eat only protobuf generated errors 
    }
  }
  return map;
}

@kennberg
Copy link
Contributor Author

kennberg commented May 8, 2012

#2 seems like a quick fix in C++ code. Do you have ideas on how to auto-generate the JS module for #3? Perhaps, it can be a part of the protobuf module that is generated.

Thanks for the loop idea. It probably makes sense to break on exception?

@kennberg
Copy link
Contributor Author

Hey, I've created and open sourced a convenience wrapper for this. Maybe there is a path that we can merge it into this module? I don't mind.

https://github.com/kennberg/node-protobuf-wrapper

@chrisdew
Copy link
Owner

See #19 for another field type which needs some form of 'retrieval type parameterisation'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants