GeoTools

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. Text File
    GEOT-2125.patch
    28/Jun/09 2:03 AM
    8 kB
    Justin Deoliveira
  2. Text File
    GEOT-2125-oracle.patch
    30/Jun/09 10:37 AM
    2 kB
    Andrea Aime
  3. Text File
    GEOT-2125-postgis.patch
    30/Jun/09 10:37 AM
    2 kB
    Andrea Aime

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. GEOT-2124 Number format in created DBF file

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Andrea Aime added a comment -
Ah hem... anyone?
Show
Andrea Aime added a comment - Ah hem... anyone?
Hide
Permalink
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
Vote (0)
Watch (2)

Dates

  • Created:
    Updated: