Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

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

    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'.
    Last edited by ppietras; 14 May 2015, 04:27.

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

    Comment


      #3
      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

      Comment


        #4
        FYI: The reason for the question is this sentence:
        Originally posted by docs
        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

        Comment


          #5
          Originally posted by Isomorphic View Post
          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.

          Comment


            #6
            Hi ppietras,
            Originally posted by ppietras View Post
            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

            Comment


              #7
              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.

              Comment


                #8
                Originally posted by Isomorphic View Post
                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

                Comment

                Working...
                X