{"action":"created","issue":{"url":"https://api.github.com/repos/grpc-ecosystem/grpc-gateway/issues/438","repository_url":"https://api.github.com/repos/grpc-ecosystem/grpc-gateway","labels_url":"https://api.github.com/repos/grpc-ecosystem/grpc-gateway/issues/438/labels{/name}","comments_url":"https://api.github.com/repos/grpc-ecosystem/grpc-gateway/issues/438/comments","events_url":"https://api.github.com/repos/grpc-ecosystem/grpc-gateway/issues/438/events","html_url":"https://github.com/grpc-ecosystem/grpc-gateway/issues/438","id":243678229,"node_id":"MDU6SXNzdWUyNDM2NzgyMjk=","number":438,"title":"any way to let int64 marshal to int not string?","user":{"login":"jinleileiking","id":93968,"node_id":"MDQ6VXNlcjkzOTY4","avatar_url":"https://avatars1.githubusercontent.com/u/93968?v=4","gravatar_id":"","url":"https://api.github.com/users/jinleileiking","html_url":"https://github.com/jinleileiking","followers_url":"https://api.github.com/users/jinleileiking/followers","following_url":"https://api.github.com/users/jinleileiking/following{/other_user}","gists_url":"https://api.github.com/users/jinleileiking/gists{/gist_id}","starred_url":"https://api.github.com/users/jinleileiking/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jinleileiking/subscriptions","organizations_url":"https://api.github.com/users/jinleileiking/orgs","repos_url":"https://api.github.com/users/jinleileiking/repos","events_url":"https://api.github.com/users/jinleileiking/events{/privacy}","received_events_url":"https://api.github.com/users/jinleileiking/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":28,"created_at":"2017-07-18T11:01:19Z","updated_at":"2018-08-06T00:02:35Z","closed_at":"2017-07-18T14:22:44Z","author_association":"NONE","body":"https://github.com/grpc-ecosystem/grpc-gateway/issues/296\r\n\r\nBut I really need this feature."},"comment":{"url":"https://api.github.com/repos/grpc-ecosystem/grpc-gateway/issues/comments/410558038","html_url":"https://github.com/grpc-ecosystem/grpc-gateway/issues/438#issuecomment-410558038","issue_url":"https://api.github.com/repos/grpc-ecosystem/grpc-gateway/issues/438","id":410558038,"node_id":"MDEyOklzc3VlQ29tbWVudDQxMDU1ODAzOA==","user":{"login":"achew22","id":37206,"node_id":"MDQ6VXNlcjM3MjA2","avatar_url":"https://avatars3.githubusercontent.com/u/37206?v=4","gravatar_id":"","url":"https://api.github.com/users/achew22","html_url":"https://github.com/achew22","followers_url":"https://api.github.com/users/achew22/followers","following_url":"https://api.github.com/users/achew22/following{/other_user}","gists_url":"https://api.github.com/users/achew22/gists{/gist_id}","starred_url":"https://api.github.com/users/achew22/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/achew22/subscriptions","organizations_url":"https://api.github.com/users/achew22/orgs","repos_url":"https://api.github.com/users/achew22/repos","events_url":"https://api.github.com/users/achew22/events{/privacy}","received_events_url":"https://api.github.com/users/achew22/received_events","type":"User","site_admin":false},"created_at":"2018-08-06T00:02:35Z","updated_at":"2018-08-06T00:02:35Z","author_association":"COLLABORATOR","body":"@kurin,\r\n\r\n> I'm not going to lie, having to use float64 instead of a more semantically appropriate type to hold integer valued data because a different programming language that I don't use is broken makes me a little bit resentful.\r\n\r\nI think that is fair. Being displeased because of these circumstance is not ideal is well justified.\r\n\r\nUnfortunately, the reality of the world we live in is that JSON hasn't aged well compared with alternative marshalling formats and is relatively restricted due to it. It's great that it existed in 1999 and it has propelled a lot of development over the years, but I, for one, am glad to see it shuffle off this mortal coil. Since it is a schemaless exchange format you're stuck dealing with the lowest common denominator of clients that receive it. Originally it was created for use in Javascript, so I guess it's a bit fitting that Javascript is what holds it back.\r\n\r\nIn this particular case if you look at the [ECMA-404 (JSON spec)](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf) for their definition of a \"number\" you will see this:\r\n\r\n> A number is a sequence of decimal digits with no superfluous leading zero. It may have a preceding minus sign (U+002D). It may have a fractional part prefixed by a decimal point (U+002E). It may have an exponent, prefixed by e (U+0065) or E (U+0045) and optionally + (U+002B) or – (U+002D). The digits are the code points U+0030 through U+0039.\r\n\r\nThat's it.\r\n\r\nOrly! No limits on how many decimals are allowed to be included? No limit on how far down the decimal places there are going to be? Thank you, JSON, for forcing me to load \"math/big\" in Go or `java.math.BigDecimal` so that I can interpret this random JSON blob. How should we handle the situation where someone sends us a 600 digit number with 600 sigfigs? Proto has to draw a line somewhere. I can easily imagine another issue being about how protobuf returns a `big.Float` which is inconvenient to use in golang instead of the much more reasonable int64 that it currently returns.\r\n\r\n> I don't think (but I'm not sure) that any of my integer values goes above 2^53; maybe they will fit in floats.\r\n\r\nFingers crossed, I ran into this issue at a company I worked at before and we had to go through the migration from 52bit ints to strings. It was horrible, just horrible.\r\n\r\nWe are trying to map JSON based REST concepts into proto3. If there are things where JSON is more flexible than proto3, then we either have to expand proto3's/our understanding to contain more stuff (see #712 for an example of that in combination with https://github.com/googleapis/googleapis/pull/512), or conform the old API to the new specs. I don't really see another way to do that -- something has to give when there is inconsistency between two APIs.\r\n\r\n> But this is really, IMO, better served by giving users a knob, even if the knob has a warning label on it.\r\n\r\nI would like to take this chance to give you that knob. If you want to change the way that grpc-gateway marshalls/unmarshalls, you can implement the your own marshaller and unmarshaller. It shouldn't take more than a few hours to put something together that handles your use case. You could even put it up on github and share it around. For more docs on this, it is the [first entry](https://grpc-ecosystem.github.io/grpc-gateway/docs/customizingyourgateway.html) in our FAQ.\r\n\r\nMaybe you could help me flesh that out with more context/content so future people don't get quite this frustrated. What do you think about that plan?"}}
{"actor":{"display_login":"achew22"}}