Problem with very large numeric values (bigint) - Smartgwt Power 4.1

[ppietras]

SmartClient Version: v9.1p_2015-05-06/PowerEdition Deployment (built 2015-05-06).
GWT version 2.6.
Tested on Firefox 24.7.0 and newer.

I used nightly build from 6 may 2015 to test it.

We use Power Edition.

Problem occurred with databound ListGrid (SQLDataSource) with very large integer values (bigint, biginteger etc). They seem to be erroneously displayed and wrong values are returned by Listgrid itself.
We have id '9223372036854775807' and it's wrongly displayed and than returned in client-side code as different value (we have custom fetches on this primary key value). The same happens for other large values. Since it's clients legacy database there is nothing we can do about thouse values.

Problem occurred on ListGrid databound to postgresql 9.4 and mssql via SQLDataSource, but as a test case you can check showcase "Edit by cell":
http://www.smartclient.com/smartgwt/...d_editing_cell

If you put value '9223372036854775807' into "Population" it will be displayed as '9223372036854776000'.

[Isomorphic]

These numbers are larger than JavaScript can natively represent with its Number type. See DataSourceField.stringInBrowser for framework options for dealing with this issue.

[Blama]

Hi Isomorphic,

after reading the linked docs for the new DataSourceField.stringInBrowser I'm wondering if it is somehow easily possible (perhaps with the SimpleType system?) to enable range validators for the range -2^53 to 2^53 for all type="integer" or type="float" fields.
Of course I could add the validators by hand, but if SimpleType supports this, that would obviously be the better solution.

I'm pretty sure that for my application (with no legacy data) the JavaScript range is enough for user data as well as PKs/FKs.

Best regards
Blama

[Blama]

FYI: The reason for the question is this sentence:

Values submitted to the server will be converted to BigInteger if they exceed the range of Java's Long type. This happens during DSRequest validation, before any defined DMI methods are called.

If interfering with DMI code, one must always do type checking for BigInteger, which means more unneeded LOC if you don't expect values out of the JavaScript range from a business perspective.

Best regards
Blama

[ppietras]

These numbers are larger than JavaScript can natively represent with its Number type. See DataSourceField.stringInBrowser for framework options for dealing with this issue.

OK. We'll look into that.
Thanks for response.

[Blama]

Hi ppietras,

OK. We'll look into that.
Thanks for response.

please note that the attribute is not in the 5.0p docs (only 5.1d).

Best regards
Blama

[Isomorphic]

You can define a SimpleType with that validation built in and use it pervasively. This just means your DataSource definitions change from type="integer" to type="myInteger" (or whatever name), so it is no additional effort over trying to change the definition of the integer type itself, which would cripple the framework and could break internal functions.

[Blama]

You can define a SimpleType with that validation built in and use it pervasively. This just means your DataSource definitions change from type="integer" to type="myInteger" (or whatever name), so it is no additional effort over trying to change the definition of the integer type itself, which would cripple the framework and could break internal functions.

Great, thank you. I'll do that.

Best regards
Blama