GeoTools
  1. GeoTools
  2. GEOT-2125

Make sure NUMBER(x,0) Oracle fields are mapped to Integer/Number

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.5.1
    • Fix Version/s: 2.7.6
    • Component/s: jdbc
    • Labels:
      None

      Description

      In Oracle there is a numeric type that allows to define the number of decimals. Make sure it maps to an integral Java type when the number of decimals is zero.
      Actually, I believe the same data type is available for other databases as well, so check if a general solution is possible.

      1. GEOT-2125.patch
        8 kB
        Justin Deoliveira
      2. GEOT-2125-oracle.patch
        2 kB
        Andrea Aime
      3. GEOT-2125-postgis.patch
        2 kB
        Andrea Aime

        Issue Links

          Activity

          Hide
          Justin Deoliveira added a comment -
          Here is a patch that does a narrowing of numeric types in this case. It only handles the case of zero decimal digits mapping to an integral type, it does not handle any narrowing of floating point types.
          Show
          Justin Deoliveira added a comment - Here is a patch that does a narrowing of numeric types in this case. It only handles the case of zero decimal digits mapping to an integral type, it does not handle any narrowing of floating point types.
          Hide
          Andrea Aime added a comment -
          The patch looks good. There is an error in the tests, the attribute names are not passed through aname before passing the names into the descriptor lookups.

          The narrowing leaves me with some doubts. Integer.MAXINT is 2147483647 which is indeed 10 digits, yet with 10 digits one can represent also number bigger than an integer could ever contain.

          Howerer, the mapping has the nice property that it's symmetric, that is, creating a integer column on Oracle with createSchema(...) will result in a NUMBER(10,0), which will map back to a integer again.

          If we took the position of mapping NUMBER(10,0) to Long instead, which gives the assurance every number contained in the column can be represented by an integer, we would not get the same symmetry (we'd ask the store to create an integer, and we'd get back a long).


          Show
          Andrea Aime added a comment - The patch looks good. There is an error in the tests, the attribute names are not passed through aname before passing the names into the descriptor lookups. The narrowing leaves me with some doubts. Integer.MAXINT is 2147483647 which is indeed 10 digits, yet with 10 digits one can represent also number bigger than an integer could ever contain. Howerer, the mapping has the nice property that it's symmetric, that is, creating a integer column on Oracle with createSchema(...) will result in a NUMBER(10,0), which will map back to a integer again. If we took the position of mapping NUMBER(10,0) to Long instead, which gives the assurance every number contained in the column can be represented by an integer, we would not get the same symmetry (we'd ask the store to create an integer, and we'd get back a long).
          Hide
          Christian Mueller added a comment -
          I see a patch for jdbc-core.

          For DB2 I do not want this behavior. The numerical data types have a bidirectional releationship to the java types.

          DB2 versus Oracle Types

          http://www.databaseanswers.org/ora_to_db2_mapping.htm

          A DB2 NUMERIC data type is a synonym for DECIMAL.

          Show
          Christian Mueller added a comment - I see a patch for jdbc-core. For DB2 I do not want this behavior. The numerical data types have a bidirectional releationship to the java types. DB2 versus Oracle Types http://www.databaseanswers.org/ora_to_db2_mapping.htm A DB2 NUMERIC data type is a synonym for DECIMAL.
          Hide
          Andrea Aime added a comment -
          In this case I guess the narrowing should be moved into the dialect to allow people free override.
          Show
          Andrea Aime added a comment - In this case I guess the narrowing should be moved into the dialect to allow people free override.
          Hide
          Andrea Aime added a comment -
          Mumble, the patches attached here allow to control type narrowing from the dialect, so I guess it's good to go?

          The thought that maybe we should allow the users to decide whether to use type narrowing crossed my mind too (factory option). However, the number of options that JDBC data stores expose is growing every day and it's becoming a little... embarassing... Maybe wait until someone complains.
          Show
          Andrea Aime added a comment - Mumble, the patches attached here allow to control type narrowing from the dialect, so I guess it's good to go? The thought that maybe we should allow the users to decide whether to use type narrowing crossed my mind too (factory option). However, the number of options that JDBC data stores expose is growing every day and it's becoming a little... embarassing... Maybe wait until someone complains.
          Hide
          Andrea Aime added a comment -
          Ah hem... anyone?
          Show
          Andrea Aime added a comment - Ah hem... anyone?
          Hide
          Christian Mueller added a comment -
          As long as you keep this logic in the dialect, you should decide.
          For DB2, the mapping is clear.

          Show
          Christian Mueller added a comment - As long as you keep this logic in the dialect, you should decide. For DB2, the mapping is clear.

            People

            • Assignee:
              Andrea Aime
              Reporter:
              Andrea Aime
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: