[ 
https://issues.apache.org/jira/browse/THRIFT-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Buğra Gedik updated THRIFT-4675:
--------------------------------
    Description: 
The code generated for JS constants involving the {{int64}} Thrift type do not 
rely on the {{Int64}} JS type (from the {{node-int64}} package Thrift uses for 
handling 64-bit integers). 

For example, consider the following Thrift constant definitions:

{code}
    const i64 MAX_INT64 = 9223372036854775807
    const i64 SMALL_INT64 = 15
{code}

This results in generating the following code:

For node.js:
{code}
    ttypes.MAX_INT64 = 9223372036854775807;  
    ttypes.SMALL_INT64 = 15;  
{code}

For the browser:
{code}
    MAX_INT64 = 9223372036854775807;
    SMALL_INT64 = 15;  
{code}

Since the JS {{number}} type cannot natively represent integers that do not fit 
into a double precision floating point, this will result in lost precision 
(printing {{MAX_INT64}} would produce {{}}). 

The correct output should be (showing for node.js):
{code}
    ttypes.MAX_INT64 = new Int64(''7FFFFFFFFFFFFFFF'');  
    ttypes.SMALL_INT64 = new Int64(15);  
{code}

Besides this, none of the Typescript type bindings ({{.d.ts}} files) contain 
the types for int64 types. This includes both the constants, types, and service 
method parameters. 

Note that fixing this may break some of the existing code. So please advise if 
this should be a separate option or not. In my mind, this is how it should work 
by default, but I don't know the policy in Thrift regarding backward 
compatibility. 

  was:
The code generated for JS constants involving the {{int64}} Thrift type do not 
rely on the {{Int64}} JS type (from the {{node-int64}} package Thrift uses for 
handling 64-bit integers). 

For example, consider the following Thrift constant definitions:

{code}
    const i64 MAX_INT64 = 9223372036854775807
    const i64 SMALL_INT64 = 15
{code}

This results in generating the following code:

For node.js:
{code}
    ttypes.MAX_INT64 = 9223372036854775807;  
    ttypes.SMALL_INT64 = 15;  
{code}

For the browser:
{code}
    MAX_INT64 = 9223372036854775807;
    SMALL_INT64 = 15;  
{code}

Since JS cannot represent integers that do not fit into a double precision 
floating point, this will result in lost precision. 

The correct output should be (showing for node.js):
{code}
    ttypes.MAX_INT64 = new Int64(''7FFFFFFFFFFFFFFF'');  
    ttypes.SMALL_INT64 = new Int64(15);  
{code}

Besides this, none of the Typescript type bindings ({{.d.ts}} files) contain 
the types for int64 types. This includes both the constants, types, and service 
method parameters. 

Note that fixing this may break some of the existing code. So please advise if 
this should be a separate option or not. In my mind, this is how it should work 
by default, but I don't know the policy in Thrift regarding backward 
compatibility. 


> JS code generators not handling int64 type properly for constants and for 
> TypeScript type mappings
> --------------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-4675
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4675
>             Project: Thrift
>          Issue Type: Bug
>          Components: JavaScript - Compiler
>    Affects Versions: 0.11.0
>            Reporter: Buğra Gedik
>            Priority: Major
>
> The code generated for JS constants involving the {{int64}} Thrift type do 
> not rely on the {{Int64}} JS type (from the {{node-int64}} package Thrift 
> uses for handling 64-bit integers). 
> For example, consider the following Thrift constant definitions:
> {code}
>     const i64 MAX_INT64 = 9223372036854775807
>     const i64 SMALL_INT64 = 15
> {code}
> This results in generating the following code:
> For node.js:
> {code}
>     ttypes.MAX_INT64 = 9223372036854775807;  
>     ttypes.SMALL_INT64 = 15;  
> {code}
> For the browser:
> {code}
>     MAX_INT64 = 9223372036854775807;
>     SMALL_INT64 = 15;  
> {code}
> Since the JS {{number}} type cannot natively represent integers that do not 
> fit into a double precision floating point, this will result in lost 
> precision (printing {{MAX_INT64}} would produce {{}}). 
> The correct output should be (showing for node.js):
> {code}
>     ttypes.MAX_INT64 = new Int64(''7FFFFFFFFFFFFFFF'');  
>     ttypes.SMALL_INT64 = new Int64(15);  
> {code}
> Besides this, none of the Typescript type bindings ({{.d.ts}} files) contain 
> the types for int64 types. This includes both the constants, types, and 
> service method parameters. 
> Note that fixing this may break some of the existing code. So please advise 
> if this should be a separate option or not. In my mind, this is how it should 
> work by default, but I don't know the policy in Thrift regarding backward 
> compatibility. 



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

Reply via email to